As I already pointed out, you don't *need* any PMC members to vote on committers in your project.
If all the current committers have voted +1, then that is all that is needed. -- Tom Jordahl WS PMC member ________________________________ From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 10:54 AM To: [email protected] Subject: Fw: [VOTE] new committers moving from pmc to general to try and reach more PMC members... ----- Forwarded by Daniel Jemiolo/Durham/IBM on 05/07/2008 10:50 AM ----- Daniel Jemiolo/Durham/IBM wrote on 04/30/2008 01:23:01 PM: > Hello PMC members, > > I started a vote to add some new committers to the Muse project last > Monday (see general and muse-dev), but we haven't received any PMC > votes yet. All of the active committers have given a +1, but these > are not binding votes. Please take the time to review the vote email > (below) and send in your vote; the nominees are willing and the > content is there, but we need some new leaders if the project is > going to move forward. > > Thanks, > Dan > > ----- Forwarded by Daniel Jemiolo/Durham/IBM on 04/30/2008 01:16 PM ----- > > Daniel Jemiolo/Durham/[EMAIL PROTECTED] wrote on 04/21/2008 03:28:50 PM: > > > Lately there has been a lot of talk on the Muse mailing list about > > pulling all of contributions from the last year together and > > creating a 2.3 release. Of course, it won't be as simple as that: > > there are lots of new features and plenty of important bug fixes > > based on real world experience with the code, but unfortunately, the > > current committers have been pulled away to other projects. I think > > that it's time to nominate some new committers, people who have > > shown that they can maintain and grow the Muse code base through > > their code contributions and time volunteered helping others on the > > mailing list. > > > > Below is the list of people that I am nominating to take on the > > responsibility of shaping, testing, and delivering Muse 2.3.0; they > > will be joined by existing committers Vinh Nguyen (Cisco) and Joel > > Hawkins (Compuware). > > > > > > Saurabh Dravid - Saurabh initially worked on the Eclipse TPTP > > project, building Eclipse tooling for Muse users. Much of his bug > > reporting (and solving) is split between Apache and Eclipse bug > > trackers, but together these two sources show that he is very > > comfortable getting knee deep in the code and solving problems. With > > that knowledge under his belt, Saurabh is now contributing new > > features around security and resource discovery, things that are > > crucial to deployers and could not be completed without lots of > > intense study and determination. > > > > Balan Subramanian - Everything I said about Saurabh can be applied > > equally to Balan. Balan has also spent years handling the legal and > > administrative issues surrounding open source development with > > Apache and Eclipse (from a corporate perspective), and is well- > > suited to review new contributions and ensure that due diligence is > > in place for all of them; the 2.3 contributions come from sources > > that are more disparate than ever, so this skill and patience is important. > > > > Chris Twiner - Chris Twiner is a 'real world' user of Muse who has > > found and cracked many tough problems in the code base. In my > > personal opinion, his contributions on MUSE-270[1] alone are enough > > to warrant nomination, but his involvement is not limited to this. > > In addition to being a significant code contributor, Chris is an > > active mailing list problem solver who often has insight that the > > original developers could not have had when they first wrote the > > code; he has also shown the tact and resourcefulness that I think is > > required to balance the needs of new users with the desire of > > developers to move forward. > > > > Kam Yee - Kam has made strong contributions in an area that is > > extremely important but often overlooked because of its difficulty: > > he has created a test harness for Muse FVT and SVT, including WS-* > > spec compliance. This is something that we've wanted for a very long > > time, but the complexity of WS-* deployment and testing has pushed > > it to the bottom of the list. I think Kam's work will be key to > > ensuring that we don't have regressions in spec compliance or in the > > tedious-but-important WSDL/SOAP/codegen issues that we face all the time. > > > > > > Committers and PMC members: please reply to muse-dev and general > > with your votes. You can either send one vote for all or vote for > > each individual separately. > > > > Here is my +1 for all four nominees. > > > > Thanks, > > Dan > > > > > > [1] http://issues.apache.org/jira/browse/MUSE-270
