Neil, Before I jump in and comment on the original e-mail, I thought it just worth stating that I don't believe anyone is making a comment that there is insufficient peer review in any given sub-project. We may need to change our processes a bit to formalise them and ensure they are demonstrable, but the main issue (I believe) is that the board wants us (the PMC) to be able to demonstrate that the correct things are happening and we are involved enough to ensure that is true.
> > From: Neil Graham <[EMAIL PROTECTED]> > Date: 19/11/2003 7:48:34 > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED], XML PMC <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: XML PMC and Oversight > > > > > > Hi Berin and all, > > Although the question of whether to split the PMC, and generally of how to > increase oversight, are interesting ones, the comments in Dirk's note about > "a release which is made without sufficient +1's votes" has generated a bit > of confusion among some Xerces-J committers. > > Historically, the project has (with one or two lapses) generally worked by > having a release manager send a note to the Xerces-J development list some > time before a release, proposing a release and inviting anyone with > concerns to air them. Silence has always been interpreted as consent, and > the releases have gone ahead accordingly. > > Are we to assume that the idea that silence is consent is no longer > sufficient? I believe Dirk has already commented that the board wants a more positive process. Note though that the requirement is PMC members need to be more involved, not necessarily that all the developers need to +1 if that makes sense. As an aside, the very fact that you guys are (quite rightly!) asking these questions says that as a project we need to ensure that all this is formalised and understood. > > If not, then there is the question of what aspecgts of a release need to be > voted on. Does the release plan have to be ratified? Does the date need > to be voted on? Or, as stated in the authoritative-sounding "Decision > Making" document availalbe from the XML website [1], do the proposed > binaries have to be tested, and then voted on to certify their soundness? > All good questions. I think this is all "standard process", so we would want to have good reason to change it as a set of minimal requirements. However.... > Actually, it would be interesting to know the status of the "Decision > Making" document itself; I don't recall the current PMC having voted on it, > so I assume it is a set of best practices; but perhaps it would be clearer > to everyone if it were amended to state that it only represented best > practices, or, etter yet, edited to represent consensus as to what the > "best practice" should be (I'm not convinced it reflects this in its > current incarnation). > I have not seen it voted on, but it may have been in other places in the ASF. However I would expect that we as a group should refine it to what we are comfortable with for the overall project. Then we should vote on accepting the result. I *strongly* believe that we cannot give the board the level of oversite it requires unless we as a project agree on what it is we should be doing for each stage of the development cycle. Otherwise the whole thing is going to de-generate into a cycle of arguments. > Any light anyone could shed would be very much appreciated! > > Cheers, > Neil > > [1]: http://xml.apache.org/decisions.html#Release+Testing > Neil Graham > XML Parser Development > IBM Toronto Lab > Phone: 905-413-3519, T/L 969-3519 > E-mail: [EMAIL PROTECTED] > > > > > > > Berin Lautenbach > > <[EMAIL PROTECTED] To: [EMAIL PROTECTED] > > m.au> cc: XML PMC <[EMAIL PROTECTED]> > > Subject: Re: XML PMC and Oversight > > 11/18/2003 05:44 > > AM > > Please respond to > > general > > > > > > > > > G'day all, > > As some of you may be aware, we asked the board to comment on how > involved the XML PMC should be in releases being made by the XML > sub-projects. This was discussed at the board meeting, and Dirk came > back with the response below (which is being forwarded in line with his > OK in the 2nd last para). > > The basic thrust is that the PMC needs to have more active oversite of > all code being committed and released within XML. > > Dirk has given two suggestions > > - grow the PMC and split into sub-groups, with each sub-group having > responsibility around code and releases of a nominated subset of > sub-projects; or > > - getting the current PMC more involved in releases and code commits of > the sub-projects. This might involve formal review e-mail lists etc. > > There are other options, and it may be that no single option makes sense > for all sub-projects. For example Xerces(C/J/P) probably has enough > active committers to grow PMC membership to 4-6, who could provide > direct oversite and report back to the broader PMC. (Does that make it > a TLP I wonder :>.) > > That approach won't work for xml-commons or xml-security who have fairly > low numbers of people, so maybe we need to aggregate a few together for > review purposes. (Note that this would not imply a visible aggregation > - they would still be separate in terms of names etc.) > > Anyway - the above are just musings for the moment. Am *very* > interested in seeing all suggestions. I am happy to write something up > as a response to the board, and write up any processes we think are > necessary, but I think we need a full discussion by all xml@ > committers/contributors here in general@ first. > > As a final thought - whatever we do, we need to think about how we > minimise overhead on all concerned, whilst ensuring we are meeting the > expectations of the board. > > Cheers, > Berin > > > Dirk-Willem van Gulik wrote: > > PMC, > > > > At the last board meeting we discussed your question about oversight. And > > we agree that we have a puzzle here. > > > > What follows is not exactly a black and white answer - but more some > > thoughs towards a solution. This because we recognize that the XML group > > (like just about every other group) is special in some respects and does > > not fit the mold perfectly. So do not take any of the text below as a > sign > > that the XML pmc is doing things fundamentally wrong or badly - it is > just > > that something is ill fitting. > > > > Now the key issue is that the board expects the PMC to carry out active > > oversight with respect to their project(s). This essentially mean that we > > exect the PMC to catch issues, say a release which is made without > > sufficient +1's votes or lack of code review and thus be very close to > the > > code literally on a day to day basis. > > > > It is our opinion that in actual practice that means that any PMC will > > either need an extremely vigilant committer in each project, or, more > > realistically several. The latter has the added advantage that > > controversial issues are more likely to be reported even if the reporter > > is party to that issue. And because of this we consider just a single > > representative on the low side. Having said that - it is of perhaps > > possible to offset this single person issue by having very regular, and > > well documented, meetings with very explicit mailing list archive review > > cycles by the other PMC members. > > > > Now for this the number of people on the PMC may grow to be virtually all > > committers, like in some other parts of the ASF. However this brings the > > additional risk that if the group is very large the feeling of > > resonsibility dillute; and that the level of oversight actually reduces > as > > no one feels personally responsible. > > > > Now given the size of the XML project - the sheer number of committers > and > > the large number of projecs - the above may simply never be realistic. > > > > So one thing we would like to ask the xml pmc to consider (or discuss on > > the XML general list) > > > > -> splitting the xml PMC into three parts as to > > make the scope more managable. > > > > and then > > > > -> aim to have 3 to NumberOfCommitters on a PMC > > for each sub project. > > > > This does not mean that the XML project needs to be spliced 'visibly' - > > and I could imagine a virtual aggregation so that [EMAIL PROTECTED] and > > xml.apache.org continue to exist. > > > > But as said above - that is just one suggestion - other options could > > revolve around the current PMC but having very regular well documented > > review sessions. But the key property of any solution is that we, as the > > board, want to 'see' realistic acitve oversight happening. > > > > So what we expect from you folks is think this over - feel free to move > it > > to general@ and/or your committer if you feel that is a more appropriate > > venue - and ideally create a position by the next board meeting, or the > > januari board meeting by the latest. > > > > And again - do not take any of the above as a vote of no convidence, we > > are at this point not seriously worried - but we do want to see how we > can > > improve things long term and make things better. > > > > Thanks, > > > > Dw. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > This message was sent through MyMail http://www.mymail.com.au --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
