For real now: bug tracking and secretary tasks in git

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

Is there a reason that the bug tracker should live outside of kernel.org? I mean pretty much everything official, the official source tree for instance, already lives on kernel.org - wouldn't having the bug tracker under the same domain make more sense?

I also thought there was some discussion about a distributed bug tracker a while back for this, what ever came of that? If I've been living under a rock about those issues please pardon my ignorance.

- John 'Warthog9' Hawley

On Fri, Jan 8, 2010 at 10:38 PM, Jan Krüger <jk@jk.gs> wrote:

Thanks for doing that!!

[This reply is a bit late, but there doesn't seem to have been much discussion, so...]

On Sat, Jan 09, 2010 at 01:38:50AM +0100, Jan Krüger wrote:

I more or less agree with your approach, though I am a bit concerned that because the process of moving information between the list and the bug tracker is manual, bits of information will be lost unless the secretaries are on their toes. Which means that people who submit bugs will see no activity on their bug, even though it may have been discussed on the list, and will consider the tracker to be crufty and useless.

But that is not so much a criticism of your proposal, as a possible thing that might go wrong. It's worth giving it a try and seeing what happens.

I notice that there are not too many bugs in the tracker right now. If this is going to be useful for ordinary users to submit bugs, it needs to be publicized. JH suggested hosting it at kernel.org. I think that is a reasonable idea, and certainly it needs a link from other git sites (the wiki, and probably git-scm.org).

As far as the choice of flyspray, I'm not strongly against it, though I suspect you would get more up-take from git developers (well, me, anyway) if it was something that had a more git-ish interface. It would be really nice to clone the bug db, edit, commit, and push bug updates. Many of the distributed trackers support that. I recognize that for ordinary users, we do still want some kind of web-based submitting and bug reading interface. Surely somebody has built a git backend on one of the existing trackers, or somebody has built a nice web interface on one of the distributed trackers? It has been a while since I looked seriously at this area, and I remember being a bit disappointed last time.

And finally, thanks for starting a discussion on this issue. We talked a little about it at the GitTogether, and what you proposed is in line with what was said there, I think. My plan going forward from that discussion (which I hadn't actually started implementing, though) was to clean up my own personal todo list and start making it a bit more public. The reason being that my list is not simply personal features, but lots of bugs posted to the list that have not been dealt with, and that I have either decided are probably actual bugs that need fixing, or even ones that I have reproduced but need prodding to move forward on. So sometime in the near future I'd like to clean up that list and dump it into whatever sort of bug tracking we end up with.

-Peff