On Sun, Jan 2, 2011 at 1:48 AM, Gordon Woodhull <gordon@woodhull.com> wrote:
Hi Dean,
I happen to agree with what you are saying about there not being much support for collaborative development before review (for people who want that), and IMO git does sound neat, but -
On-going development of the library can follow that model and the "review" becomes more a regular part of daily things that happen on the developer's mailing list. The "management" of the review could be as simple as setting up a Wordpress Poll or something similar to get an actual "vote" from the members of the community -- not in an anonymous manner of course.
You are undervaluing what a review manager does here. A big part is to moderate the discussion, find points of agreement, and work out compromises on individual points - as well as deciding where there is not going to be agreement at all. A poll would certainly not cover this. It is more like consensus-building than voting. I could imagine tools that would help with this (e.g. email re-threading), but I haven't seen any yet.
Right, I missed that part completely. I guess a poll wouldn't work as well. How about if the review was posted as Trac/Redmine/Jira issues on the projects instead and where the review manager can curate the discussion accordingly? The progress of which can be kept track of in a Wiki which eventually becomes a "living record" of the actual review process -- meaning, especially in Trac, issues can be linked to from the Wiki and as such they can technically be referenced, cross-referenced, and collected accordingly. Comments in the issues should typically stay "on-topic" and thus moderating the discussion on issues would be a part of the normal chores for a review manager (or managers).
In a way a review manager is an advocate for the library who is not as ego-burdened as the author(s).
+1 to that. I agree completely.
Sure, but that doesn't make the process collaborative -- which is actually my main "beef" with the current way things are going. And, even if someone were to re-write a signals implementation, there's no need to actually fork it as a separate project as it could very well just be an evolution of the implementation and just get the contribution in as part of the normal process. Then, the release managers just make a determination of whether to actually get a certain version of the signals implementation from one repo, or get another from another repo.
This seems to shift a lot of the decision-making to the release managers, who are already overworked. Review managers can better focus on their individual libraries and judge whether the conditions on acceptance were fulfilled. Joachim's proposal for review manager assistants would lighten their workload considerably.
Well, not entirely on the release managers really. More on the community of trusted developers alongside the release managers. The logic goes this way: Given: - there are Release Managers whose main purpose is to make sure that the upcoming release is in a shippable state - there are Trusted Developers working on the integration and stabilization effort on releases - there are a list of libraries that are considered part of the Boost distribution Then: - a release will consist of snapshots of releases from individual libraries packaged as a whole - there may be patches made on the official distribution as part of the stabilization effort across Boost distributions releases, which should be submitted back "upstream" to the individual libraries - the "developer community" around a particular library (I put that in quotes because that can very well be one person) then manages the development of that particular library and all patches made to that library So in that situation there are two places where a potential contributor can get involved in: in the evolution of an existing library (for example, signals), or the stabilization of releases and gain status as a "trusted developer" through the web of trust system (as alluded to by the GPG key signing mechanism, etc.). You lower the barrier in this situation two ways: 1. You allow for more chances for people to contribute in a less-obtrusive manner. No need to get permission to get commit access to the sandbox/trunk to get started with contributing. 2. You allow individual libraries to grow communities and/or evolve/mature independently. Note that the status quo would be a subset of this larger scheme, which means people can keep working on a single Boost repository (may it be Git or Subversion) and libraries can still evolve outside of Boost getting integrated into the Boost repository later. There's nothing really being removed in the process if you look at it, the current process would still be supported in this expanded process to lower the barrier to entry.
Maybe there is a case for maintenance review managers?
I haven't gotten that far yet though. ;) I usually just call that the community, which is more fluid -- no need to put a label on that role which pretty much any Boost contributor would do in the case of submitting patches and making sure that libraries being used are maintained accordingly. :D
This is a complex social process, and tools aren't going to make it easy. But they can help people make better judgements, and follow through better.
Definitely. Although I think the tools you use increases the upper bound on the productivity of a group in general. All other things being equal, better tools usually gives you a better advantage. ;)
Thank you for raising many interesting ideas,
You're welcome, and thank you for the thoughtful response as well. :D -- Dean Michael Berris about.me/deanberris