Trac, bugs and patches
It sounds boys did a pretty good job at the symfony camp last week end.
Fabien came back to me with a smile and showed me this :
You will find the orginal following this URL : ttp://trac.symfony-project.com/trac/wiki/TicketWorkflow
«Here is the way we are going to manage bugs and patches» he said !
In order to let symfony programmers focus on developping the next release we are trying to set up a way to handle the huge volume of remarques, bugs and patches posted everyday on trac. Each ticket has now a new field named «Qualification» that describes how is the issue while the ticket is in the open state. It could be one of these values :
- «Unreviewed», the issue/patch has not been sorted yet.
- «Design decision» means you will probably hear of it on the dev mailing list
- «Accepted», the bug could be reproduced and a solution is to be found
- «Ready for core team», a patch fixing the problem and matching symfony development guidelines is proposed with accurate documentation and tests
- «Patch rejected, quality issue», do I need to explain that ?
After a glance at the tickets list, Noel and I were a bit discouraged. A new kind of trac moderator able to change tickets qualification and make the system to live was needed. This role is called «developper dispatcher». If you are willing to help symfony and share a bit of your time please feel free to make the trac to live. Anyone who feel skilled enough can do it today. We felt your involvment in symfony should be as simple as that. If you see a ticket and have the same issue, the trac is yours. If you find a ticket and do not know what decision to make, please make a post on the dev mailing list.
Happy coding ! ;o)
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.