Hi all,
I''m trying to work more on the development page[1], and I''m
having
some trouble. It''s not really with the page per se, but rather with
trying to get a handle on Puppet''s development process.
Currently, my development work has focused on generally short-term
goals: Fixing known bugs, providing features that clients have paid
for, or providing things that I think are important. The project is
getting complicated enough that this is not working any more,
especially since we now have 100+ open tickets, with most of them
being enhancement requests.
So, I want to try to define a process by which ideas turn into code.
My goal is not to build some fixed beaurocratic process, but rather
to find a way to give the community an idea of what''s being worked on
(both so they know what''s coming in the future, but also so they know
how to get involved) and to make sure I''m working efficiently (e.g.,
I spend too much time worrying about what I should work on next,
because I''ve got 100+ tickets I could work on, plus 10 projects that
have been discussed on the lists, plus my 10 projects I want to do,
plus 10 more things that I know I want but don''t know how to do).
Here are the issues I see:
- Most of my planned work is not mentioned on the wiki at all. E.g.,
there are no pages about moving the node/class mapping to a separate
tool, having a special syntax for relationships in the language,
moving from XMLRPC to REST, and lots more. I''m willing to make these
pages, but I''m concerned that doing so might not be much benefit, and
that the pages will quickly become out of sync with reality. How can
I document what I want to do in a way that people will interact with,
and hopefully provide feedback and/or help on?
- There are way too many open enhancement requests to be usable as a
flat list. Either enhancements need to moved out of the ticket db or
we need a classification system for handling these enhancements, so
it''s abundantly clear which enhancements are being worked on, which
are accepted but not planned (i.e., I''d accept a patch that
implemented it, but I''m not going to do it myself), which are
significant changes, which are easy, etc. It might be sufficient to
create a new ticket type or two, maybe agree on some keywords, and
then write a couple of custom ticket reports, both some for finding
these categories of tickets and some for ignoring them.
- Community members have no good way to know what I and other
developers are working on, either now or in the near future. I know
I have a list of things I want to work on, and although I can''t
really guarantee any of them, since just about anyone with money can
allocate a significant chunk of my time for custom development, I can
at least say, here''s what I''ll probably be doing and in this
order.
Also, not many people really know what portions of Puppet are being
worked on by whom (e.g., Blake doing all of the Rails work), nor any
associated priorities.
- Community members have no good way of knowing where they can help
in the development process. Clearly we need to work on other areas
of community involvement, since we''re not all developers nor should
we be, but developing Puppet needs to be more approachable than it
currently is. A well-managed enhancement database might be a big
boon here, especially if people could find enhancements that were
straightforward and already "approved"; mostly, though, people need a
way to browse potential development work, hopefully finding something
they want and is already described.
- It''s currently difficult or impossible to tell whether a given
feature is fully spec''ed, just a vague idea, or a mere hope. This is
something that''s really critical to me, since it''s difficult
for me
to stay conscious of all of the questions I need answered before I
can work on a given problem; having a list of projects that still
need significant specification work would make it easy for me to keep
them in mind and think about them during my time on the bicycle or
whatever.
I''m sure there are other issues with the development process, but it
can mostly be summed up as: There isn''t one, and our project is now
big enough with enough people involved that there should be. I want
to be to get up in the morning with a clear list of the development
work I should do, and I want people interested in development to know
where they can start, and I want people to be able to easily get a
basic timeline for future Puppet development.
Any feedback people can provide would be greatly appreciated.
1 - https://reductivelabs.com/trac/puppet/wiki/PuppetDevelopment
--
I cannot and will not cut my conscience to fit this year''s fashions.
-- Lillian Hellman
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> SNIP <> Here are the issues I see: > > - Most of my planned work is not mentioned on the wiki at all. E.g., > there are no pages about moving the node/class mapping to a separate > tool, having a special syntax for relationships in the language, > moving from XMLRPC to REST, and lots more. I''m willing to make these > pages, but I''m concerned that doing so might not be much benefit, and > that the pages will quickly become out of sync with reality. How can > I document what I want to do in a way that people will interact with, > and hopefully provide feedback and/or help on?I''ve found wiki''s to be poor at publishing this type of "dynamic" information. Wiki''s are great for things that don''t change much, but not for rolling .plan files. At least with my own projects and request tracker queue, which has large numbers of open requests, it''s been best for me to prioritize each ticket and then generate a report page I can quickly go to and quickly kill tickets from the top of the stack. I also create RT tickets at work for everything, no matter how small or theoretical, just so they''re in the queue. Multiple queues help here. Could you setup a bug queue, a small enhancements queue, and a "big changes" queue where all of the ideas are sortable by priority?> - There are way too many open enhancement requests to be usable as a > flat list. Either enhancements need to moved out of the ticket db or > we need a classification system for handling these enhancements, so > it''s abundantly clear which enhancements are being worked on, which > are accepted but not planned (i.e., I''d accept a patch that > implemented it, but I''m not going to do it myself), which are > significant changes, which are easy, etc. It might be sufficient to > create a new ticket type or two, maybe agree on some keywords, and > then write a couple of custom ticket reports, both some for finding > these categories of tickets and some for ignoring them.Could tags be used here? e.g. tag a ticket as wontfix, willacceptpatch, with a note that it''s not a priority item? How about an "user" named "the community". Start assigning tickets to it. =) I''m half serious here, it''d at least give an indication it''s not something you''re working on rather than everything under the sun being assigned to you.> - Community members have no good way to know what I and other > developers are working on, either now or in the near future. I know > I have a list of things I want to work on, and although I can''t > really guarantee any of them, since just about anyone with money can > allocate a significant chunk of my time for custom development, I can > at least say, here''s what I''ll probably be doing and in this order. > Also, not many people really know what portions of Puppet are being > worked on by whom (e.g., Blake doing all of the Rails work), nor any > associated priorities.I think tickets are the way to go here too, with one caveat. I personally don''t know what the work itself is, let alone who''s doing it. e.g. I think I''d have to run and test the rails work to find out what the rails work is.> - Community members have no good way of knowing where they can help > in the development process. Clearly we need to work on other areas > of community involvement, since we''re not all developers nor should > we be, but developing Puppet needs to be more approachable than it > currently is. A well-managed enhancement database might be a big > boon here, especially if people could find enhancements that were > straightforward and already "approved"; mostly, though, people need a > way to browse potential development work, hopefully finding something > they want and is already described.I don''t see this as a huge problem. If a document emerges clearly stating how things are done around here, new people could dive right in and say "Hey, I''m good at wiki articles, there''s the template I use." or "Here''s the template for bug reports and feature requests."> - It''s currently difficult or impossible to tell whether a given > feature is fully spec''ed, just a vague idea, or a mere hope. This is > something that''s really critical to me, since it''s difficult for me > to stay conscious of all of the questions I need answered before I > can work on a given problem; having a list of projects that still > need significant specification work would make it easy for me to keep > them in mind and think about them during my time on the bicycle or > whatever.If I submit a feature request, part of the approval process could be requesting the requester create a wiki page detailing the specs...> I''m sure there are other issues with the development process, but it > can mostly be summed up as: There isn''t one, and our project is now > big enough with enough people involved that there should be. I want > to be to get up in the morning with a clear list of the development > work I should do, and I want people interested in development to know > where they can start, and I want people to be able to easily get a > basic timeline for future Puppet development.I agree completely, though I think everything technically speaking is already in place in the form of Trac. It''s just a matter of clarifying it''s use, no?> Any feedback people can provide would be greatly appreciated. > > 1 - https://reductivelabs.com/trac/puppet/wiki/PuppetDevelopment > > -- > I cannot and will not cut my conscience to fit this year''s fashions. > -- Lillian Hellman > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.comCheers, -- Jeff McCune The Ohio State University Department of Mathematics Systems Manager _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Apr 3, 2007, at 2:46 PM, Jeff McCune wrote:> > I''ve found wiki''s to be poor at publishing this type of "dynamic" > information. Wiki''s are great for things that don''t change much, but > not for rolling .plan files.Ok, so focus on the ticket database for handling the queue and the ordering, which means everything should be in it. We''ll still need to have wiki documents for specifications of the larger projects, but smaller ones will likely survive fine without them.> At least with my own projects and request tracker queue, which has > large > numbers of open requests, it''s been best for me to prioritize each > ticket and then generate a report page I can quickly go to and quickly > kill tickets from the top of the stack. > > I also create RT tickets at work for everything, no matter how > small or > theoretical, just so they''re in the queue. Multiple queues help here. > Could you setup a bug queue, a small enhancements queue, and a "big > changes" queue where all of the ideas are sortable by priority?So now we just need to find a way to develop queues in the ticket db. Conversation on IRC concluded that keywords are probably the right answer, so I''ll start building a list of specific keywords to use along with what they mean. I expect we''ll need multiple dimensions -- e.g., how fully specified the task is, the expected complexity, whether it''s an entirely new functionality or a modification of existing functionality (maybe it''s sufficient to state whether it''s got backward compatibility concerns), and whether the project leads approve of the enhancement. Any more? We''ll use milestones for noting the state of a ticket -- whether it''s planned (i.e., assigned to a specific milestone), and maybe a few more.> Could tags be used here? e.g. tag a ticket as wontfix, > willacceptpatch, > with a note that it''s not a priority item?Whatever we use, I specifically want it to be possible to make queries to find tickets that do or do not match, so tags or keywords probably work fine, but notes likely won''t.> How about an "user" named "the community". Start assigning tickets to > it. =) I''m half serious here, it''d at least give an indication it''s > not something you''re working on rather than everything under the sun > being assigned to you.I think that''s a brilliant idea.>> - Community members have no good way to know what I and other >> developers are working on, either now or in the near future. I know >> I have a list of things I want to work on, and although I can''t >> really guarantee any of them, since just about anyone with money can >> allocate a significant chunk of my time for custom development, I can >> at least say, here''s what I''ll probably be doing and in this order. >> Also, not many people really know what portions of Puppet are being >> worked on by whom (e.g., Blake doing all of the Rails work), nor any >> associated priorities. > > I think tickets are the way to go here too, with one caveat. I > personally don''t know what the work itself is, let alone who''s > doing it. > e.g. I think I''d have to run and test the rails work to find out what > the rails work is.If we get good about having pages describing the work we''re doing (i.e., most work will result from a ticket, and the complicated work will have an associated specification document), then this won''t be as big a problem.>> - Community members have no good way of knowing where they can help >> in the development process. Clearly we need to work on other areas >> of community involvement, since we''re not all developers nor should >> we be, but developing Puppet needs to be more approachable than it >> currently is. A well-managed enhancement database might be a big >> boon here, especially if people could find enhancements that were >> straightforward and already "approved"; mostly, though, people need a >> way to browse potential development work, hopefully finding something >> they want and is already described. > > I don''t see this as a huge problem. If a document emerges clearly > stating how things are done around here, new people could dive > right in > and say "Hey, I''m good at wiki articles, there''s the template I > use." or > "Here''s the template for bug reports and feature requests."Yeah, but everything''s a catch-22 -- I''m not going to spend tons of time making it easy for the community to get involved until I''m sure it''s going to get more done overall, and the community''s not going to get as involved until they''ve got sufficient resources to know how to do so.>> - It''s currently difficult or impossible to tell whether a given >> feature is fully spec''ed, just a vague idea, or a mere hope. This is >> something that''s really critical to me, since it''s difficult for me >> to stay conscious of all of the questions I need answered before I >> can work on a given problem; having a list of projects that still >> need significant specification work would make it easy for me to keep >> them in mind and think about them during my time on the bicycle or >> whatever. > > If I submit a feature request, part of the approval process could be > requesting the requester create a wiki page detailing the specs...Yeah, definitely. There are certainly plenty of tickets that still need to be specified.>> I''m sure there are other issues with the development process, but it >> can mostly be summed up as: There isn''t one, and our project is now >> big enough with enough people involved that there should be. I want >> to be to get up in the morning with a clear list of the development >> work I should do, and I want people interested in development to know >> where they can start, and I want people to be able to easily get a >> basic timeline for future Puppet development. > > I agree completely, though I think everything technically speaking is > already in place in the form of Trac. It''s just a matter of > clarifying > it''s use, no?Yeah, I would think so. I''ll see if I can come up with different tag categories and the tags we''ll use in them. -- Barrow''s first law: Any Universe simple enough to be understood is too simple to produce a mind able to understand it. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Ok, I''ve got some example pages up. Here''s the list of queries that I figure will be the most important: https://reductivelabs.com/trac/puppet/wiki/DevelopmentKeywords It has a list of a few milestone-related queries, then has sets of keywords all related to a dimension of development (e.g., difficulty, detail level). Each of the keywords is a link to a custom page that has the results of the query plus links to the other queries of this type (e.g., the ''easy'' page has links to ''medium'' and ''hard''), a link to a form for making a custom query (with the specific query filled in), plus a link to the top Keywords page. I''ve only created one example keyword page: https://reductivelabs.com/trac/puppet/wiki/EasyTickets I''ve written a short script that generates both the top-level page, plus the content for each of the additional pages. I haven''t yet done so, but I would just hook this script up to trac-admin, such that it would generate all of these pages in one fell swoop, so it''d be pretty easy to regenerate any of these pages if necessary. The only thing the app can''t easily do, from what I can tell, is set the tags. This feels kind of hackish, because I feel like I''m statically generating a web application, but I think it''s about the best we can do and stay in Trac. Note that this keyword list is my proposed final list, so I''m asking for comments both on the set of pages and on the specific keywords and keyword dimensions I''ve chosen. Also, I''ve (of course) not yet documented the whole process by which a person might use these keywords, which I fully expect to do once we''ve settled on a solution. The only other example I could find of something doing something like this is Rails: http://weblog.rubyonrails.org/2006/6/2/all-about-rails-trac-keywords I''ve gone, um, quite a bit further than their usage. Comments? -- The most incomprehensible thing about the world is that it is at all comprehensible. --Albert Einstein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Apr 3, 2007, at 11:33 PM, Luke Kanies wrote:> Ok, I''ve got some example pages up. > > Here''s the list of queries that I figure will be the most important: > > https://reductivelabs.com/trac/puppet/wiki/DevelopmentKeywords > > It has a list of a few milestone-related queries, then has sets of > keywords all related to a dimension of development (e.g., > difficulty, detail level). Each of the keywords is a link to a > custom page that has the results of the query plus links to the > other queries of this type (e.g., the ''easy'' page has links to > ''medium'' and ''hard''), a link to a form for making a custom query > (with the specific query filled in), plus a link to the top > Keywords page.Unfortunately, it looks like you can''t create queries that can do an AND filter on multiple keywords, which means we can''t easily create, say, a query for low-hanging fruit (approved, easy tickets) nor for tickets that aren''t classified using the given set of keywords (e.g., neither easy, medium, nor hard). This almost feels like it''s a killer to this, since those are only semi-complex queries, yet we can''t even do those. -- Between two evils, I always pick the one I never tried before. -- Mae West --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Apr 4, 2007, at 12:28 AM, Luke Kanies wrote:> > Unfortunately, it looks like you can''t create queries that can do > an AND filter on multiple keywords, which means we can''t easily > create, say, a query for low-hanging fruit (approved, easy tickets) > nor for tickets that aren''t classified using the given set of > keywords (e.g., neither easy, medium, nor hard). > > This almost feels like it''s a killer to this, since those are only > semi-complex queries, yet we can''t even do those.Okay, I figured out that you *can* do queries for tickets missing all of the specified values (now available under the None link on the EasyTickets[1] page). It still looks like you can''t do AND queries with multiple keywords. Also, I haven''t really figured out whether all of these categories should only apply to enhancement requests -- which seems intuitive -- or whether some or all of them should apply to defects, too. 1 - https://reductivelabs.com/trac/puppet/wiki/EasyTickets -- I also realize I can no longer spell "pseudo". My fingers have now hard-wired "sudo". Thanks, Unix! I also cannot uppercase "cat" for the life of me. --Jonathan Rentzsch --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 4/4/07, Luke Kanies <luke@madstop.com> wrote:> On Apr 4, 2007, at 12:28 AM, Luke Kanies wrote: > > > > Unfortunately, it looks like you can''t create queries that can do > > an AND filter on multiple keywords, which means we can''t easily > > create, say, a query for low-hanging fruit (approved, easy tickets) > > nor for tickets that aren''t classified using the given set of > > keywords (e.g., neither easy, medium, nor hard). > > > > This almost feels like it''s a killer to this, since those are only > > semi-complex queries, yet we can''t even do those. > > Okay, I figured out that you *can* do queries for tickets missing all > of the specified values (now available under the None link on the > EasyTickets[1] page). It still looks like you can''t do AND queries > with multiple keywords. > > Also, I haven''t really figured out whether all of these categories > should only apply to enhancement requests -- which seems intuitive -- > or whether some or all of them should apply to defects, too. > > 1 - https://reductivelabs.com/trac/puppet/wiki/EasyTickets > > -- > I also realize I can no longer spell "pseudo". My fingers have now > hard-wired "sudo". Thanks, Unix! I also cannot uppercase "cat" for > the life of me. --Jonathan Rentzsch > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >Hi Luke, I''d recommend checking out what the Django guys did with their trac ticket system. They''ve created a simplified form [1] for new tickets, a reports page [2] and modified the normal form for easier triaging of tickets. It is mostly documented here [3] which plugins they used to achieve this. [1] http://code.djangoproject.com/simpleticket [2] http://code.djangoproject.com/wiki/Reports [3] http://code.djangoproject.com/wiki/HackingTrac -- matthew http://wadofstuff.blogspot.com
On Apr 4, 2007, at 6:58 AM, Matthew Flanagan wrote:> Hi Luke, > > I''d recommend checking out what the Django guys did with their trac > ticket system. They''ve created a simplified form [1] for new tickets, > a reports page [2] and modified the normal form for easier triaging of > tickets. It is mostly documented here [3] which plugins they used to > achieve this. > > [1] http://code.djangoproject.com/simpleticket > [2] http://code.djangoproject.com/wiki/Reports > [3] http://code.djangoproject.com/wiki/HackingTracThis is *very* helpful. Some of the plugins are things I''ve been looking for anyway -- e.g., those that allow messing with the nav bars. It looks like they''re doing something pretty similar to what I''m doing, but they''ve got direct support in the tickets, rather than the keyword hacks I''m doing. In particular, I didn''t know about this feature: http://trac.edgewall.org/wiki/TracTicketsCustomFields Clearly I just need to add custom fields to the tickets and then use the simpleticket plugin to make it so only developers can manage most of those fields. Thanks! -- I wanna hang a map of the world in my house. Then I''m gonna put pins into all the locations that I''ve traveled to. But first, I''m gonna have to travel to the top two corners of the map so it won''t fall down. -- Mitch Hedberg --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Apr 4, 2007, at 6:58 AM, Matthew Flanagan wrote:> Hi Luke, > > I''d recommend checking out what the Django guys did with their trac > ticket system. They''ve created a simplified form [1] for new tickets, > a reports page [2] and modified the normal form for easier triaging of > tickets. It is mostly documented here [3] which plugins they used to > achieve this. > > [1] http://code.djangoproject.com/simpleticket > [2] http://code.djangoproject.com/wiki/Reports > [3] http://code.djangoproject.com/wiki/HackingTracBased on this whole process, I''ve redone all of the work I did yesterday. Here''s the new reports page: https://reductivelabs.com/trac/puppet/wiki/Reports I''ve also set up the simpleticket stuff, so the majority of this is invisible in the ticket creation page. At this point, the reports link direclty to Custom Query pages, rather than the per-keyword page I planned on doing. The benefit of doing it this way is that it''s really easy, and you get ''next ticket''/''previous ticket'''' links in the query. The benefit of having pages for each keyword is that it makes it a bit easier to select among the different keywords. Comments? What do people think? Assuming people are happy with this, I''m going to spend the rest of my spare time categorizing tickets. -- There are three kinds of death in this world. There''s heart death, there''s brain death, and there''s being off the network. -- Guy Almes --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> Comments? What do people think? > > Assuming people are happy with this, I''m going to spend the rest of > my spare time categorizing tickets.Looks good. It''s quite clear. -- Jeff McCune Systems Manager The Ohio State University Department of Mathematics _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On 4/5/07, Luke Kanies <luke@madstop.com> wrote:> On Apr 4, 2007, at 6:58 AM, Matthew Flanagan wrote: > > Hi Luke, > > > > I''d recommend checking out what the Django guys did with their trac > > ticket system. They''ve created a simplified form [1] for new tickets, > > a reports page [2] and modified the normal form for easier triaging of > > tickets. It is mostly documented here [3] which plugins they used to > > achieve this. > > > > [1] http://code.djangoproject.com/simpleticket > > [2] http://code.djangoproject.com/wiki/Reports > > [3] http://code.djangoproject.com/wiki/HackingTrac > > Based on this whole process, I''ve redone all of the work I did > yesterday. Here''s the new reports page: > > https://reductivelabs.com/trac/puppet/wiki/Reports > > I''ve also set up the simpleticket stuff, so the majority of this is > invisible in the ticket creation page. > > At this point, the reports link direclty to Custom Query pages, > rather than the per-keyword page I planned on doing. The benefit of > doing it this way is that it''s really easy, and you get ''next > ticket''/''previous ticket'''' links in the query. The benefit of having > pages for each keyword is that it makes it a bit easier to select > among the different keywords. > > Comments? What do people think? > > Assuming people are happy with this, I''m going to spend the rest of > my spare time categorizing tickets.Looks good except that the New Ticket link in the nav bar still goes to the non-simplified form.> > -- > There are three kinds of death in this world. There''s heart death, > there''s brain death, and there''s being off the network. -- Guy Almes > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >-- matthew http://wadofstuff.blogspot.com
On Apr 4, 2007, at 11:29 PM, Matthew Flanagan wrote:> > Looks good except that the New Ticket link in the nav bar still goes > to the non-simplified form.Yeah, those plugins apparently never made it into the template I use to build my Trac configurations, so they worked for a while but got lost during one of the rebuilds. Should be fixed now, along with having a link to the ''reports'' page in the nav bar. Now if I could just figure out how to add a link to notify people on changes to the document... -- A Chemical Limerick: A mosquito cried out in pain: "A chemist has poisoned my brain!" The cause of his sorrow was para-dichloro diphenyltrichloroethane -- Dr. D. D. Perrin --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com