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

[Dan Wells]

Hello all,

I am trying to let things play out as much as possible, but I do wish to point out a couple facts.

First, reviewing code is hard.  Unfortunately, reviewing ideas is *much* harder.  Arguing about ideas and plans is like punching at the air, but once there is code, it has meat and bones.  The code is the idea incarnate.  Granted, it is wise and helpful to post ideas and plans, and maybe someone will see an obvious flaw, or have a great idea to add.  But in all the years I have been with this project, that sort of feedback is very rare, and has even more rarely resulted in a design change before any code had been produced.  Perhaps we can somehow do better, but I think it is fair to expect that some code may require major revision upon review.

Second (and I hesitated to bring this up for fear that it might be construed as blame, and I don't want that), the code which prompted much of this conversation *did* get some feedback 4 months ago.  See the discussion at ~10:13am here:

http://evergreen-ils.org/irc_logs/evergreen/2013-11/%23evergreen.08-Fri-2013.log

I don't know how much code had already been written at that point, but some of us at that time tried to express ideas and concerns about the proposed solutions.  The feedback wasn't taken too seriously, and I didn't really have a problem with that, because I couldn't say with any certainty that the issues I raised would be a problem until I could review the code itself.  (Conceptual problems have a way of working themselves out, eventually.)

For what it's worth,
Thanks,
Dan


Daniel Wells
Library Programmer/Analyst
Hekman Library, Calvin College
616.526.7133

From: open-ils-dev-bounces at list.georgialibraries.org [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Tim Spindler
Sent: Wednesday, March 05, 2014 12:39 PM
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] a request regarding development communication in the bug tracker

I am wondering also if there is some way to get a timely response when someone post their ideas for development especially when it means a signficant structural change.   I know this is difficult because all of the work (other than contracted development) is completed by volunteers with full time jobs.  However, the community needs to find a way to prevent issues like this recurring where someone posts specs and blueprints laying out how they will solve the problem for which they were contracted but does not receive comments or concerns until the coding is done.

I'm wondering if it is possible to have some kind of signoff on the concept before coding begins or put deadlines for comments?

Tim Spindler

On Wed, Mar 5, 2014 at 12:18 PM, Ryan Eby <ebyr at aadl.org<mailto:ebyr at aadl.org>> wrote:
As someone who watches/talks development rather than actively develops I have to give a +/-1 to the discussion on list though +1 to Kathy's suggestions about always recording. This also seems from later emails that this may be more of a discussion about Launchpad being the wrong bug tool or some other process change needed to group all the avenues together.

+1 ) Things need as many eyes on them as possible and if the noise ratio is too high then this won't happen. There are probably other solutions to this, like digests of titles of any bugs commented on that day that are labeled 'design', not counting status changes, etc. However this is obviously already an issue so some sort of solution, if even temporary, would be good.

-1 ) Commit messages and change logs reference bug id's, not email thread ids (though I guess they could). As an end user when seeing a change it is extremely helpful to have the discussion about that change associated with it. Email threads haven't always been easy to find and I've had to have committers point me the way. It can also be a lot of wasted time trying to find a discussion when one might never have happened. Having a single "record" of decision making and implementation I think is useful for end users but I can be convinced if too difficult on the development standpoint. This again may be a Launchpad issue or a need of adding the process of linking to threads / irc logs in bug comments.

To the developers who participated the discussion may end/archive when the commit is made but as an end user the future need of being able to look up easily "why would it do it this way" is important. So regardless what solution is decided I think this should be kept in mind.

Another benefit in the design in the easy cross linking of issues as time passes (at least on github). This allows you to see the discussion of why something was added and then removed, settings groups as Dan mentioned, and the like. These have been helpful as an end user with some of the projects I've used that are on Github and whose discussions tend to stay in issues and pull requests. Maybe I'm just used to other projects but I see bugs referencing bugs more likely than email threads linking back to threads, and those would still only be one way. It really gives a historical view of features and decision making.

I'm not as concerned about the longevity of mailing list vs bugs. I would hope this group would migrate/preserve either going forward. The migration scripts of launchpad -> github issues I saw all added a LP#### to the bug for searching so the lookup from commits would still be easier than digging through email archives.

Just my two cents that add to zero.

-----
Eby


On March 5, 2014 at 9:49:40 AM, Kathy Lussier (klussier at masslnc.org<mailto:klussier at masslnc.org>) wrote:
> Hi Chris,
>
> Thank you for sending this e-mail! For the past week, I've been mulling
> over the issue of how we can improve the process of proposing
> development projects, particularly those that are large in scale or
> change existing functionality, and to see more collaboration among
> developers earlier on in the process. I think we can all agree there was
> a breakdown in the process for this particular project.
>
> Development plans were shared early on through Launchpad and through an
> e-mail to the general list. However, I think one constant challenge is
> capturing the attention of fellow developers to get their feedback at
> the time you need it. Let's face it, we're all busy, and we all have
> been in a situations where we're so wrapped up in other projects (i.e.
> our jobs) that we might not be able to give feedback on a project at the
> time it is sought. Sometimes, you hit gold and you get a lot of early
> feedback that helps you adapt your development plans. But it doesn't
> always happen.
>
> I give a +1 for these discussions occurring on the general list, but I
> would like to think more about how to improve that collaboration early
> on to help the process run more smoothly. A couple of ideas I've had:
>
> - IRC discussions about a particular project need to be recorded
> somewhere. I understand that the real-time nature of IRC sometimes makes
> it easier to collaborate on a development project, but, once those
> conversations are over, they need to be recorded either on the Launchpad
> report or in the ongoing e-mail thread. I would like to see
> reservations or support for a particular development approach to be
> recorded in the LP report or e-mail thread as well.
>
> - I would like to propose that proposals for large development projects
> or those that change existing functionality be placed on the agenda for
> developers meetings. The plans should be shared a few days before those
> meetings to give developers a chance to review them. I think this helps
> the issue where development projects shared via the proper channels
> don't always receive the feedback they otherwise would have received if
> everyone were paying close attention. The developers meetings are one
> time during the month where one developer can get the attention of all
> the other committers in the community. Of course, the results of those
> discussion should also be recorded in any ongoing e-mail threads.
>
> Thanks again Chris!
>
> Kathy
>
>
> Kathy Lussier
> Project Coordinator
> Massachusetts Library Network Cooperative
> (508) 343-0128<tel:%28508%29%20343-0128>
> klussier at masslnc.org<mailto:klussier at masslnc.org>
> Twitter: http://www.twitter.com/kmlussier
>
> On 3/5/2014 8:58 AM, Sharp, Chris 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!
> >
> > Thanks,
> >
> > Chris
> >
>
>



--
Tim Spindler
tjspindler at gmail.com<mailto:tjspindler at gmail.com>


P   Go Green - Save a tree! Please don't print this e-mail unless it's really necessary.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140305/7ac4273c/attachment-0001.htm>