On 18.03.2013 06:56, Peter Koželj wrote: > Unfortunately, for the better or for the worse, this is obviously not the > Apache way.
Eh? There is no "Apache Way" when it comes to managing projects, other than the premise that recoghition is gained by merit, not by decree, and that no-one has the power to dictate how a project will be run -- such decisions should, in general, be reached by consensus. > But I am always opened to alternatives. Obviously there are dozens of > Apache projects with large communities > that seem to manage without much backing from their ticket systems just > fine. I am curious... > > At the very minimum, we do need to move the discussions from Tickets to > mailing lists as it's a Apache requirement, > if I understand correctly. You misunderstand. Neither Greg nor I ever said anything about requirements, but we do have opinions about efficiency and inclusiveness. Every developer is required to be subscribed to the development list. Major decisions e.g, votes, happen on the list. Therefore, by keeping discussions on the mailing list, rather than in a completely disconnected issue tracking system, you'll reach more interested parties. Moreover, it's /harder/ to keep track of comments on the tickets than it is to keep track of discussions on the list. There is nothing wrong with using issue trackers to track bugs, or even tasks. I myself have used issue trackers as a project management tool -- but in different circumstances. Let me try to give a concrete example: This community has decided to introduce "Bloodhound enhancement proposals" as a formalized procedure for defining and accepting feature definitions. Fine. But, why then, once the feature has been designed and documented, take the extra step of breaking it down into separate tasks and creating tracker entries for those -- instead of just writing code? The exact same level of oversight can be achieved, with much less context switching and overhead, simply by writing informative log messages -- which are, IMO, a lot more useful to someone who tries to understand the reasoning behind a certain piece of code from commit history. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
