[OPEN-ILS-DEV] a request regarding development communication in the bug tracker

[Dan Scott]

On Wed, Mar 5, 2014 at 8:58 AM, Sharp, Chris <csharp at georgialibraries.org>wrote:

> Good Morning All,
>
> I've had my head down with local projects since early January, so I'm just
> now able to tune in a bit on 2.6 development.  I was just chatting with Ben
> Shum about some 2.6 new features and I came across the discussion happening
> on https://bugs.launchpad.net/evergreen/+bug/1198465.  The discussion
> goes pretty deeply into the rationale for the features being proposed
> and/or developed, and I would like to request that those sorts of
> discussions happen here on this list rather than within the dark depths of
> Launchpad.
>
> I happen to subscribe to Launchpad bug mail, so I get every communication
> of new bugs, status changes, and comments added, but I don't always have
> the time/bandwidth to tune in to every email that comes through (especially
> during bug retargeting times like now).  I do, however, read every email
> that comes to this and the Open-ILS-General lists.  When I first started
> learning about the inner workings of Free and Open Source Software
> projects, I purchased "Producing Open Source Software" by Karl Fogel (
> http://producingoss.com/), which I think is a great guide for projects
> like ours written by a veteran of the Subversion project (one of our SFC
> cousins, incidentally).  In his chapter on communication, he has a section
> entitled "No Conversations in the Bug Tracker", that I think is worth a
> read: http://producingoss.com/en/bug-tracker-usage.html.
>
> Given the availability and higher visibility of this list, the difficulty
> of navigating/searching Launchpad, and perhaps most importantly, the fact
> that we have recurring discussions about ditching Launchpad in favor of
> some other bug tracker, I'd like to request that we have discussions like
> the one on bug 1198465 on the public lists instead.  I'm welcome to
> alternative opinions on this, so feel free to respond frankly!
>

+1

I read through this bug a few days back and had similar thoughts. I have
been guilty of participating in (at least one, probably more) conversation
in the bug tracker in the past where the discussion veered heavily back
into design rather than straight-up implementation. That said, it's tough
to distinguish between design and implementation sometimes as you iterate
over code commits, where the implemented behaviour ends up revealing an
unanticipated design decision or fundamental miscommunication.

In any case, trying to keep the bulk of the design discussion in the lists
also helps documentation writers and QA-oriented people, who might in this
case envision the possible combinations of the suggested six settings that
would be added to control the behaviour of crediting/voiding and throw up
their hands at any realistic way of sanely documenting and ensuring the
reliability of anything beyond the default settings.

Yes, "there is some sensitivity in the community of the over-settingization
of Evergreen". For good reason: pain teaches rational actors to avoid
repeating the steps that led to that pain. Anyone who has been bitten by
taking advantage of non-default features or settings that worked great when
they were initially created but then were forgotten about and broken in
subsequent upgrades can attest to this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140305/85139f2f/attachment-0001.htm>