On 9/10/05, Murray Collingwood <[EMAIL PROTECTED]> wrote: > I am very happy to contribute towards the development of Struts (since Craig > invited > me) however I'm still kinda new so I might not be much use for a while. So, > here I am > sticking up my virtual hand and asking "what would you like me to do?" as a > volunteer > does.
The first thing any prospective volunteer should do is review the "How to Help" FAQ, which includes several concrete suggestions. * http://struts.apache.org/faqs/helping.html It would also be helpful, but not required, for newcomers to review the How the ASF works pages. * http://apache.org/foundation/how-it-works.html and our project guidelines * http://struts.apache.org/bylaws.html A followup suggestion to the How to Help FAQ would be for someone to review, apply, and report on some or all of the 22 enhancements with patches. There's a link on the Roadmap page to the Bugzilla issues. * http://struts.apache.org/roadmap.html#Bugzilla A very helpful thing would be for someone to review the 252 outstanding Bugzilla enhancement sugggestions, and summarize them in some way. We don't want to jettison them all, we just want to find someway to handle the backlog gracefully. At this point, my only suggestion is to extend the "Idea Jar" page. * http://wiki.apache.org/struts/StrutsIdeaJar Then perhaps we can work them into the Roadmap for Struts 1.7 and beyhond. There are also several milestones on the roadmap that will need coding. The next in line are the "experimental interfaces". The elephant in the room is that our first crack at the new Request Processing chain is no where near as slick as we would like. Someone interested in that can start by reviewing the Commons CoR documentation and code, the MailReader example in the sandbox, and the Core 1.3 code. * http://jakarta.apache.org/commons/chain/ * http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/mailreader-chain/?rev=280105 * http://svn.apache.org/viewcvs.cgi/struts/core/trunk/conf/java/chain-config.xml?view=markup There are also some OnJava articles on Chain * http://www.onjava.com/lpt/a/5671 * http://www.onjava.com/lpt/a/5693 Right now, our implementation is too much like a template and too little like a true chain. Struts Classic 1.3.x is built with Maven (maven.apache.org). I'm working on the documentation updates now. In the meantime, there's a Wiki page on the Maven build here: * http://wiki.apache.org/struts/StrutsMaintenanceMaven > > Some of the responses we have had indicate that 'committers' are making > direction > decisions rather than the PMC. The role of the PMC is to control the > project. It sounds > from some responses that our 'committers' (some not all) have their own > agendas and > this is being accepted by the PMC. As a volunteer (contributor) I should be > doing what > the PMC ask me to, otherwise they aren't "in control" and I'm not really a > volunteer. The "How it works document" does say that "The PMC as a whole is the entity that controls the project, nobody else.", but the PMC does *not* control through delegation. The PMC members *are* the committers. In the normal course, after a committer has been active for six months or so, we will invite the comitter to join the PMC (or explain why we are not). The goal of an ASF project is for all the committers to be PMC members. A guiding principle of the Apache Way is "them that do the work, make the decisions". This phrase is actually a double-entendre. We do make some decisions by voting (very few), but the real decisions are made when a volunteer does the work. Otherwise, because we are a volunteer organization, nothing actually happens. Even when we vote, there is an implication of volunteering. If a PMC member "vetos" a code change, the PMC member is obligated to produce a sound technical reason *or* an alternate implementation. If neither of these things happen, then the veto is not binding. Likewise, when we vote +1 on a release, we are also pledging to actively support the release by applying patches and answering questions. It's not about having an opinion, it's about being ready, willing, and able to do the work. > > SUMMARY > -------------- > Maybe my view is a little altruistic or idealistic. I would like to see the > PMC take control > of the project and assign those tasks identified below (by Craig) to the > volunteer > developers that work on this project. As mentioned, the PMC members *are* the volunteer developers that work on this project. When a new volunteer starts submitting patches, and conducting themselves well on the lists, after about six months, we invite them to join us as a Committer. After another six months, a Committer becomes a PMC member. Committers volunteer for tasks as our schedules permit. If one of us stops volunteering altogether for more than six months, then we change that individual's status from "active" to "emeritus". If the volunteer's schedule changes later, and they want to become active again, we change their status back. (This just happened with David Geary.) What's important to remember is that contributing to a project is not "work" for us. We have an itch, and contributing to the project helps us scratch that itch. Experience has shown us that simply assigning work to people doesn't scratch itches, at least not for long. People have to want to do the task, and they have to volunteer to do it. > > Craig, if there is anything from your list you feel I could have a go at, > please send it my > way. > > Kind regards > mc > > PS "Voting feet stuck perfectly where mouth is!" - attrib: me, just now --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
