{"thread":{"id":"22140","subject":"For real now: bug tracking and secretary tasks in git","startedAt":"2010-01-09T00:38:50Z","lastAt":"2010-01-26T12:26:55Z","messageCount":4,"participants":["Jan Krüger","J.H.","Thiago Farina","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"131152","messageId":"20100109013850.16f82412@perceptron","threadId":"22140","inReplyTo":null,"subject":"For real now: bug tracking and secretary tasks in git","fromName":"Jan Krüger","fromEmail":"jk@jk.gs","sentAt":"2010-01-09T00:38:50Z","receivedAt":"2010-01-09T00:38:50Z","isPatch":false,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"I thought about Cc'ing everyone who was involved in previous\ndiscussions about this but that would have been a huge list so I\ndidn't. No more introductory stuff needed; onwards to the wonderfully\nformatted proposal thingy!\n\nI) SUMMARY OF EVERYTHING THAT EVER HAPPENED\n-------------------------------------------\n\nMass consensus in previous discussions[1][2] goes a bit like this:\n\n1. It would be desirable to have people who do the work of interfacing\n   between bug reporters and developers. These same people could make\n   sure reports didn't get lost. These people are the *secretaries*.\n   They should be pretty reliable.\n\n2. People who contribute to git shouldn't be forced to work with the\n   tracker. Having a tracker that isn't actively maintained by dedicated\n   secretaries is pretty much worthless anyway, so there's no need to\n   pretend that forcing developers to use a tracker interface is any\n   kind of improvement.\n\n3. The \"human element\" is important. For example, automatic reminders\n   are a lot less valuable than reminders from an actual person.\n\nII) PROPOSAL\n------------\n\nOf course, since I am semi-formally proposing this, I'm also\nvolunteering to make it happen, BUT I think that no single person can\nhandle all the list traffic conscientiously enough to do a really good\njob. This proposal can only work if more volunteers are found. If you\n(and of course I'm speaking to YOU personally now) want to help out,\nspeak up now!\n\nThe proposal goes like this:\n\n* Set up bug tracker (done; it's at http://gitbugs.jk.gs/).\n* Optionally make it an official public bug tracker.\n* To conform to (2) above, tasks are only ever assigned to secretaries.\n  Whoever assigns a task to himself is responsible for finding someone\n  to actually get the task done, and to keep that person on his toes.\n  The bug tracker has features that make this easier (there is no\n  actual field for \"assigned to external entity 'dscho'\" in the\n  interface because there is no bug tracker software that doesn't suck,\n  but a comment gets the job done, and you can send reminders to\n  yourself).\n* Tasks filed by the general public get pre-screened by secretaries;\n  worthwhile tasks are (semi-manually, to conform with (3)) forwarded to\n  this list. The task is updated with summaries of whatever gets\n  discussed on the list whenever appropriate.\n* Tasks get pruned mercilessly to remove anything that is irrelevant,\n  e.g. comments that do not contribute anything to getting the task\n  done.\n* Things reported to the list get posted to the bug tracker by\n  secretaries (unless, for example, patches have already been accepted\n  by a maintainer), in order to be able to keep track of them more\n  easily. The task contains links to list discussions related to it.\n  To make it easier for a group of secretaries to collaborate, and for\n  any interested party to see the progress of a discussion, whenever a\n  secretary adds a task to the tracker, he replies to the list post\n  that prompted him to do so, with a subject starting with\n  \"[TASK]\" (ideally containing the task's summary line, too) and the URL\n  of the task in the message body.\n\nAdvantages:\n\n* Secretaries don't need to coordinate their activities much. As such,\n  there can be dozens of secretaries without scalability issues, which\n  would reduce the workload on each of them.\n* People who report things don't have to involve themselves in a\n  technical discussion that may be completely over their heads. For\n  example, when Joe Randomuser reports that a certain command does weird\n  things, he most likely won't want to hear anything about whether the\n  current strategy for confabulating stochastic index entries in a\n  distributed manner is error-free, nor does he benefit at all from\n  getting all that technical stuff delivered to his mailbox.\n* People who report things can have more confidence that their report\n  doesn't get lost in The Noise(tm).\n* Git developers don't have to deal with incomplete/nonsensical reports\n  all if they are submitted to the tracker.\n* Git developers can choose themselves how much they want to interact\n  with the bug tracker.\n\nDisadvantages:\n\n* There is a certain level of redundancy in this approach. It's not\n  clear to me whether that's a bad thing. I tend to think that it isn't.\n\nIII) THIS SECTION IS USELESS\n----------------------------\n\nHaving section headings for just two sections looked stupid, so here is\nanother one.\n\nIf there are no general objections to the proposal, I will start using\nthe tracker for tracking less-than-all reports posted to this list.\nWhether the tracker really takes off depends on everyone who reads\nthis... and I'm sure there are lots of great ideas that just didn't\noccur to me that you guys can share here.\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/108109\n[2] http://thread.gmane.org/gmane.comp.version-control.git/110117\n"},{"id":"131160","messageId":"4B47E1E0.7040600@eaglescrag.net","threadId":"22140","inReplyTo":"20100109013850.16f82412@perceptron","subject":"Re: For real now: bug tracking and secretary tasks in git","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2010-01-09T01:54:40Z","receivedAt":"2010-01-09T01:54:40Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"> The proposal goes like this:\n> \n> * Set up bug tracker (done; it's at http://gitbugs.jk.gs/).\n> * Optionally make it an official public bug tracker.\n\nIs there a reason that the bug tracker should live outside of\nkernel.org?  I mean pretty much everything official, the official source\ntree for instance, already lives on kernel.org - wouldn't having the bug\ntracker under the same domain make more sense?\n\nI also thought there was some discussion about a distributed bug tracker\na while back for this, what ever came of that?  If I've been living\nunder a rock about those issues please pardon my ignorance.\n\n- John 'Warthog9' Hawley\n"},{"id":"131189","messageId":"a4c8a6d01001091222t8e4586td2423504dfd43ea7@mail.gmail.com","threadId":"22140","inReplyTo":"20100109013850.16f82412@perceptron","subject":"Re: For real now: bug tracking and secretary tasks in git","fromName":"Thiago Farina","fromEmail":"tfransosi@gmail.com","sentAt":"2010-01-09T20:22:21Z","receivedAt":"2010-01-09T20:22:21Z","isPatch":false,"sender":{"key":"tfransosi@gmail.com","avatar":"https://avatars.githubusercontent.com/u/970071?v=4"},"body":"On Fri, Jan 8, 2010 at 10:38 PM, Jan Krüger <jk@jk.gs> wrote:\n> The proposal goes like this:\n>\n> * Set up bug tracker (done; it's at http://gitbugs.jk.gs/).\nThanks for doing that!!\n"},{"id":"132673","messageId":"20100126122654.GA28179@coredump.intra.peff.net","threadId":"22140","inReplyTo":"20100109013850.16f82412@perceptron","subject":"Re: For real now: bug tracking and secretary tasks in git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-01-26T12:26:55Z","receivedAt":"2010-01-26T12:26:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[This reply is a bit late, but there doesn't seem to have been much\ndiscussion, so...]\n\nOn Sat, Jan 09, 2010 at 01:38:50AM +0100, Jan Krüger wrote:\n\n> Mass consensus in previous discussions[1][2] goes a bit like this:\n> \n> 1. It would be desirable to have people who do the work of interfacing\n>    between bug reporters and developers. These same people could make\n>    sure reports didn't get lost. These people are the *secretaries*.\n>    They should be pretty reliable.\n> \n> 2. People who contribute to git shouldn't be forced to work with the\n>    tracker. Having a tracker that isn't actively maintained by dedicated\n>    secretaries is pretty much worthless anyway, so there's no need to\n>    pretend that forcing developers to use a tracker interface is any\n>    kind of improvement.\n> \n> 3. The \"human element\" is important. For example, automatic reminders\n>    are a lot less valuable than reminders from an actual person.\n\nI more or less agree with your approach, though I am a bit concerned\nthat because the process of moving information between the list and the\nbug tracker is manual, bits of information will be lost unless the\nsecretaries are on their toes. Which means that people who submit bugs\nwill see no activity on their bug, even though it may have been\ndiscussed on the list, and will consider the tracker to be crufty and\nuseless.\n\nBut that is not so much a criticism of your proposal, as a possible\nthing that might go wrong. It's worth giving it a try and seeing what\nhappens.\n\nI notice that there are not too many bugs in the tracker right now. If\nthis is going to be useful for ordinary users to submit bugs, it needs\nto be publicized. JH suggested hosting it at kernel.org. I think that is\na reasonable idea, and certainly it needs a link from other git sites\n(the wiki, and probably git-scm.org).\n\nAs far as the choice of flyspray, I'm not strongly against it, though I\nsuspect you would get more up-take from git developers (well, me,\nanyway) if it was something that had a more git-ish interface. It would\nbe really nice to clone the bug db, edit, commit, and push bug updates.\nMany of the distributed trackers support that. I recognize that for\nordinary users, we do still want some kind of web-based submitting and\nbug reading interface. Surely somebody has built a git backend on one of\nthe existing trackers, or somebody has built a nice web interface on one\nof the distributed trackers? It has been a while since I looked\nseriously at this area, and I remember being a bit disappointed last\ntime.\n\nAnd finally, thanks for starting a discussion on this issue. We talked a\nlittle about it at the GitTogether, and what you proposed is in line\nwith what was said there, I think. My plan going forward from that\ndiscussion (which I hadn't actually started implementing, though) was to\nclean up my own personal todo list and start making it a bit more\npublic. The reason being that my list is not simply personal features,\nbut lots of bugs posted to the list that have not been dealt with, and\nthat I have either decided are probably actual bugs that need fixing, or\neven ones that I have reproduced but need prodding to move forward on.\nSo sometime in the near future I'd like to clean up that list and dump\nit into whatever sort of bug tracking we end up with.\n\n-Peff\n"}]}