For real now: bug tracking and secretary tasks in git

For real now: bug tracking and secretary tasks in git

[Jan Krüger]

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

Re: For real now: bug tracking and secretary tasks in git

[J.H.]

> 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.

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

Re: For real now: bug tracking and secretary tasks in git

[Thiago Farina]

On Fri, Jan 8, 2010 at 10:38 PM, Jan Krüger <jk@jk.gs> wrote:
> The proposal goes like this:
>
> * Set up bug tracker (done; it's at http://gitbugs.jk.gs/).
Thanks for doing that!!

Re: For real now: bug tracking and secretary tasks in git

[Jeff King]

[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:

> 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.

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