On 30 September 2015 at 14:31, Joshua D. Drake <j...@commandprompt.com> wrote: > > On 09/30/2015 11:23 AM, Christopher Browne wrote: > >> It's well and nice to think that an issue tracker resolves all of this, >> and, if we >> had tiny numbers of issues, we could doubtless construct a repository >> indicating so. (Seems to me that the bit of "fan service" for GitHub's >> bug tracker fits into that perspective on things...) > > > CMD has over a 1000 customers. All of those that are active have a Redmine tracker. Our current ticket count is over 70k. Without it, we would never be able to service them correctly. > > What you describe is not a tool problem, it is a people problem. That exists regardless of the tool. The tool is designed to (in theory) make the people problem, less. > > In CMDs considerable experience while not only developing, consulting, writing docs, maintain repos, and confidential information... it would be impossible to achieve without Redmine at our core. > > JD > > (I am sure other tools provide the same level of service, it is just what we use)
There's nothing there for me to disagree with, which presumably means that we're somehow talking past each other. And it's not just "presumably"; there's a clear place for there to be a disconnect. It's perfectly reasonable that CMD would (and presumably does) make the proper curation of Redmine data an informal condition of employment. People want to stay working at CMD? They have to keep their issue tracking data in good form. At best, they'll experience the wrath of The Drake, and I'll leave the worst to you! :-) That curation effort is entirely more challenging to impose for a project like PostgreSQL. If I decline to fill in the RT information (assuming RT were chosen), there's no basis for someone "firing" me from the PostgreSQL project. I'd be entirely surprised to find a "curation-free" system; I've worked with RT and Bugzilla, and both require some periodic efforts to go back and make sure issues are kept in good order (for which "curation" is a very good word). It's pretty thankless work, which is why open source projects that use such systems wind up with pretty messy sets of data. It's not totally a tool problem, but once you've chosen a tool, there's some concommittant people problems that fall out of the entropy of the resulting system. And I think it was reasonable for Merlin to question the notion of the tool solving the problem. For a tool to help requires commitment to curation efforts. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
