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

[Ryan Eby]

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) 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
> 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
> >
>  
>