On 4/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > * Proposed Change:
I should mention that proposals for change are best sent to [EMAIL PROTECTED] This list is meant for people who want help using a product. Changes to the project are best discussed on [EMAIL PROTECTED] We should get back on task as to the role of each list, and :) stop annoying people who just want to know how to use the taglibs :) > First, let me make clear that this proposal does NOT change the existing > mechanism by which someone is invited to be a committer. That decision > still rests soley with the PMC. This proposal only seeks to build on > top of that mechanism. I propose that a community-based nomination > process be instituted. For the sake of discussion, a "qualified" person > is anyone that has been on the Struts Dev and/or User mailing lists for > at least 6 months and has been relatively active (say, at minimum, 2 > posts per week total). The main reason we make someone a committer is so that he or she can commit directly to the repository, without waiting for someone else to apply a patch. Aside from posting to the mailing list, or commenting on issue tickets, an important aspect of being "active" should be submitting patches that actually change the content of the repository. (Otherwise there is no practical reason for the individual to be a committer.) The "tipping point" for committer nominations is typically whether an individual submits useful patches. In the "How to Help" FAQ, we say: ---- In an ASF project, like Apache Struts, volunteers who make sustained contributions to the project are invited to become "Committers". In due course, Committers are invited to join the Project Management Committee (PMC). A goal of the ASF is for all Committers to be on the PMC. By "sustained", we mean that an individual has been active in the project for at least six months. The contributions should come in the form of both patches (to code or documentation), and posts to the mailing lists. Patches must be competent and accepted into the repository. Posts must be consistently helpful, friendly, and collaborative. The most important characteristic in a prospective Committer is an amicable demeanor that fosters goodwill. * http://struts.apache.org/helping.html ---- > Any qualified person is eligible for nomination, > or to nominate someone else. Naturally, a person could never nominate > themselves. A nomination must then be seconded by another qualified > person. At that point, a voting period of one week commences, where any > non-committer and non-PMC member, "qualified" or not, may vote (the > usual +1, 0, -1). The original nominator is responsible for tallying > the vote. A person must receive at least 60% +1's (i.e., 6 out of 10 > must be +1) and no more than half of the remainder may be negative. At > the end of that one week period, the vote results will be posted to the > Dev list and a similar one week period will commence where existing > Struts team members vote for the nominee. Also note that at any point, > the nominee can decline the nomination. We wouldn't want to offer > someone up that doesn't want to job! Back at Jakarta, we used to have committer votes on public lists, and I saw a lot of those go very wrong. People would use them as an excuse to talk about something else. It's hard to have a candid discussion about a *person* on a public list. As it turns out, the Apache HTTPD team has never had discussions about people on a public list. I think that is a much better way to go. We announce the tallies for the committer votes that succeed, but we don't embarrass people by announcing votes and discussions that fail. Being popular on the mailing lists is a good thing. But, mailing list posts don't get us any closer to releases. As a practical matter, we need people who create code and documentation, *and* who can get along with the other committers. The committers must be a set of people who can and will do the work *and* collaborate without a lead developer or other boss pulling the strings. > > * Conclusion: > Once again, let me make perfectly clear that the existing PMC still > retains 100% control over who is invited to join. This proposal only > serves to introduce a mechanism by which members of the community can be > nominated and force a vote by the PMC. If you want to "force" a vote by the PMC, why not just bring one up on [EMAIL PROTECTED] But, please, check with the nominee first, to be sure he or she wishes to be discussed on a public list in this way. A better approach might be to send your nomination to the PMC chair and ask that it be forwarded to the PMC list. Based on votes I've seen at Jakarta and other PMC lists, the usual form is something like this: ---- The nominee has been an active contributor to the project for more than six months. The nominee's posts to user@ and dev@ are consistently helpful. The nominee often participates in development discussions in a collaborative way. The nominee has submitted code and patches and collaborated on changes that were accepted to the code base. * << link to report showing the nominee's patches >> Here's my +1. ---- > That is of course the first > important principle of this proposal. The other important principle is > taking the will of the community into account. By having the PMC not > vote until AFTER the community has voted, the "will of the community" > should be apparent, and the idea is that the PMC will take that into > account when voting. The community will then have a clear indication > whether they have been listened to or not based on the outcome of the > vote (and the comments made during the vote because, after all, there > ould be legitimate reasons not to adhere to the community's vote, and > hose reasons should come out in discussion). >From an ASF perspective, the "community" is not everyone who subscribes to the mailing list and downloads the product. The community is the set of individuals who contribute to the project, both by making helpful posts to the mailing list *and* by contributing useful code and documentation. Downloads don't make the product possible. Contributions make the product possible. Our customers are the contributors, who pay for the product with posts and patches. An ASF project is about creating a collaborative community of developers, who do the work and make the decisions. It's not just about creating a product for other people to download. It's about creating and maintaining the product that we want to use ourselves, and sharing that product with others who might also find it useful. Users are our way of finding new contributors. If we've overlooked someone who is making helpful posts, submitting useful patches, and who also works well with others, please let me know. In the case of patches, please also include links to several tickets that were applied. Over the years, I think there have been exactly two committer nominations here that failed, and both times the failed nominees had not submitted a single patch. > But, at the end of the > day, who is invited to join is still decided by the PMC, as it is today. :) Well, yeah. We're the ones that have to live with the decision, long after whoever "voted" on the nomiantion might have unsubscribed and faded away. :) Who I would feel sorry for is all the people who might be nominated, and then turned down, on a public list, without ever even asking to be nominated or discussed in a public forum. This isn't about making legislation or winning a popularity contest. We need people who *can and do* create code or documentation and *collaborate* with other team members, without a suit or "lead developer" pulling the strings. > * Rationale > One of the issues that a number of people seem to have with the way > Struts has progressed is the seeming inability (or difficulty at least) > of getting "new blood" involved. As Craig mentions, six new committers joined us in the last year, along with seven others in the WebWork merger. That seems like quite a lot of "new blood" to me. > There seems to be a perception by many > that there is a bit of a "closed club" mentality with regard to being > invited in as a committer and that the Struts community at large has no > say in the matter. All of our development resources are managed in the open. Any one can download the source, report an issue, submit a patch, write to the wiki, or post to the unmoderated lists. What's more, under the Apache License, anyone who is willing to do the work can take the codebase and start their own project. We are prudent when it comes to direct write access to the repository. We use the repository to generate releases, and the ASF takes releases, and supporting releases, very seriously. It's not just about slapping code together and seeing if it sticks. It's about being ready, willing, and able to support the product over the long haul. When someone does make sustained and welcome contributions to the codebase and to the lists, I do believe we've been asking those people to join us as committers. If there are people we haven't invited, I'd suggest it's either an oversight, or because a person's contributions have been one-sided, all patches or all posts. One blind spot right now might be the wiki. Some people have been making some great contributions to the wiki, but because they don't go into the repository, they don't seem like patches. But, we should start considering wiki contributions to be as valuable as contributions to the other documentation. > I look forward to feedback. Thanks for listening! And thanks for this post, and all the other helpful posts you and so many others make to the list. > > Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
