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

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

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?"

Reply via email to