I thought about Cc'ing everyone who was involved in previous discussions about this but that would have been a huge list so I didn't. No more introductory stuff needed; onwards to the wonderfully formatted proposal thingy! I) SUMMARY OF EVERYTHING THAT EVER HAPPENED ------------------------------------------- Mass consensus in previous discussions[1][2] goes a bit like this: 1. It would be desirable to have people who do the work of interfacing between bug reporters and developers. These same people could make sure reports didn't get lost. These people are the *secretaries*. They should be pretty reliable. 2. People who contribute to git shouldn't be forced to work with the tracker. Having a tracker that isn't actively maintained by dedicated secretaries is pretty much worthless anyway, so there's no need to pretend that forcing developers to use a tracker interface is any kind of improvement. 3. The "human element" is important. For example, automatic reminders are a lot less valuable than reminders from an actual person. II) PROPOSAL ------------ Of course, since I am semi-formally proposing this, I'm also volunteering to make it happen, BUT I think that no single person can handle all the list traffic conscientiously enough to do a really good job. This proposal can only work if more volunteers are found. If you (and of course I'm speaking to YOU personally now) want to help out, speak up now! The proposal goes like this: * Set up bug tracker (done; it's at http://gitbugs.jk.gs/). * Optionally make it an official public bug tracker. * To conform to (2) above, tasks are only ever assigned to secretaries. Whoever assigns a task to himself is responsible for finding someone to actually get the task done, and to keep that person on his toes. The bug tracker has features that make this easier (there is no actual field for "assigned to external entity 'dscho'" in the interface because there is no bug tracker software that doesn't suck, but a comment gets the job done, and you can send reminders to yourself). * Tasks filed by the general public get pre-screened by secretaries; worthwhile tasks are (semi-manually, to conform with (3)) forwarded to this list. The task is updated with summaries of whatever gets discussed on the list whenever appropriate. * Tasks get pruned mercilessly to remove anything that is irrelevant, e.g. comments that do not contribute anything to getting the task done. * Things reported to the list get posted to the bug tracker by secretaries (unless, for example, patches have already been accepted by a maintainer), in order to be able to keep track of them more easily. The task contains links to list discussions related to it. To make it easier for a group of secretaries to collaborate, and for any interested party to see the progress of a discussion, whenever a secretary adds a task to the tracker, he replies to the list post that prompted him to do so, with a subject starting with "[TASK]" (ideally containing the task's summary line, too) and the URL of the task in the message body. Advantages: * Secretaries don't need to coordinate their activities much. As such, there can be dozens of secretaries without scalability issues, which would reduce the workload on each of them. * People who report things don't have to involve themselves in a technical discussion that may be completely over their heads. For example, when Joe Randomuser reports that a certain command does weird things, he most likely won't want to hear anything about whether the current strategy for confabulating stochastic index entries in a distributed manner is error-free, nor does he benefit at all from getting all that technical stuff delivered to his mailbox. * People who report things can have more confidence that their report doesn't get lost in The Noise(tm). * Git developers don't have to deal with incomplete/nonsensical reports all if they are submitted to the tracker. * Git developers can choose themselves how much they want to interact with the bug tracker. Disadvantages: * There is a certain level of redundancy in this approach. It's not clear to me whether that's a bad thing. I tend to think that it isn't. III) THIS SECTION IS USELESS ---------------------------- Having section headings for just two sections looked stupid, so here is another one. If there are no general objections to the proposal, I will start using the tracker for tracking less-than-all reports posted to this list. Whether the tracker really takes off depends on everyone who reads this... and I'm sure there are lots of great ideas that just didn't occur to me that you guys can share here. [1] http://thread.gmane.org/gmane.comp.version-control.git/108109 [2] http://thread.gmane.org/gmane.comp.version-control.git/110117 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html