On Wed, Mar 5, 2014 at 8:58 AM, Sharp, Chris <csh...@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.