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

[Tim Spindler]

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


-- 
Tim Spindler
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/30c593b9/attachment-0001.htm>