forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav...." <brightoncomput...@brightontown.com.au>
Subject RE: [Proposal] Project Management Roles
Date Wed, 26 Apr 2006 12:25:00 GMT
I agree with the proposal, I think some structure and co-ordination
Has value and will help the project receive focus. Some people having
A targeted purpose will be good, others have their own or company agendas
As to why they are here and that is of course fair enough.

A little more commenting inline , 

> -----Original Message-----
> From: David Crossley [mailto:crossley@apache.org]
> Sent: Wednesday, 26 April 2006 3:43 PM
> To: dev@forrest.apache.org
> Subject: [Proposal] Project Management Roles
> 
> An idea has occurred to me recently. Each of you will see
> parts of your recent statements and ideas incorporated.
> Let us discuss this and see if it would work for us.
> 
> --------------------------------------
> Background
> ----------
> 
> Each project PMC is tasked with "creation of a set of
> bylaws intended to encourage open development and
> increased participation in the Forrest Project".
> See the "resolution" link in
> http://forrest.apache.org/guidelines.html#pmc
> 
> We have partially completed our Guidelines. It is up to us
> how we define our Guidelines. Each project is deliberately
> given scope to do whatever they see fit.
> 
> At Forrest we don't seem to be gaining sufficient momentum
> with the "increased participation" side of things. We seem
> to be relying on various capable and over-dedicated people.
> If this situation continues, then i see the project would
> dwindle and certain individuals would become burnt out.
> 
> --------------------------------------
> Proposal
> --------
> 
> Establish "Project Management Roles" for various
> well-defined tasks (see below).
> 
> The concept is to have one particular PMC member to
> volunteer for each role. No limit to the number of roles
> that one can do.
> 
> Having responsibility seems to enable people to feel
> more a part of the project. People feel more responsible
> for doing a job when they officially have that function.
> That helps the jobs to get done.

I agree, however this comment and this proposal is mainly
Geared towards PMC Members (with the last exception).
As I see it, if you are a PMC Member, how much more does
One need to feel 'responsible', the position (honour)implies it.
(The position does not imply responsibility of a particular
Role though)

I would not have thought you would need to encourage role
Responsibility for PMC Members to get an outcome of
Community Growth. It will I suspect encourage more focused
Use of code and Issue solving and therefore releases should
Come around quicker.

If role responsibilities of PMC members pass across to the
Developer community in general, giving better direction
And purpose to developers, then this is what would encourage
Community spirit and growth, in turn getting more done.

If you say to Developer X, do what you like, scratch your own
Itch, it is sort of implying 'do what you like, we appreciate
It but have our own more important things to take care of' .

That last statement was maybe unfair but didn't know how to word
It better. But the scope you give the developer in that sense is
Huge, and they may get lost, at least to begin with.

If you instead said to Developer X, how about you concentrate
On going through the Roadmap, or how about you sort out the CSS
Or see what you can do to improve Y, who wants to look at Z.

With that, you are saying, we 'need' this doing, it would benefit
The project immensely and it is something worth doing.

 
> 
> This is not intended to put pressure on people to force
> them to do work nor "pull their weight". If they fail to
> do their task, then someone else will be able to do it.
> By virtue of having a well-defined role, it will get done
> somehow.
> 
> Most roles have minimal tasks and are not too onerous.
> For example, for the "Documentation Coordinator", the only
> job might be to publish the documentation every Friday.
> Sure it can be done at other times and other people can
> do it too, but at least it gets done once per week.
> 
> Having a person doing a role does not mean that everyone
> can leave it to them and rely on them. Anyone else can
> dive in and do the job (for example, publish the docs
> twice per week). The more people who are familiar with
> the role, the better. Perhaps the person actually doing
> that role will notice that there can be improvements to
> how they are doing it.
> 
> Having the roles regularly fulfilled means that the
> project will be able to flow more smoothly.
> 
> These are not elected positions. They are filled only
> by volunteers. If no-one valunteers then we stumble along
> as we do now, i.e. rely on some other poor bugger.
> 
> If a person is dissatisfied with the way a particular
> role is being done, then they can volunteer to take over.
> 
> If a person feels that someone else has been doing a
> stirling effort, but might need a rest, then offer to
> take over. The current person might say "no it is okay,
> you concentrate on so-and-so". Perhaps the current person
> should relunctantly give up their role that they think
> they are doing a good job at. Give someone else a chance.
> You can always still assist the old role.
> 
> No need for a time limit. Keep going until someone else
> wants to do it, or you ask to be replaced.
> 
> Each role should have some continually enhanced
> documentation about it, so that if the person is away,
> then some other PMC member can more easily do it.
> 
> Find a way to offer constructive criticism, perhaps by
> assisting or enhancing the role documentation.
> 
> There are no roles for "leadership" of technical areas.
> We don't have the concept of leadership at the ASF.
> Rather these are "functional roles".
> 
> --------------------------------------
> The Roles
> ---------
> 
> There are two roles that we have already defined:
> PMC Member and PMC Chair. There are two other roles that
> we already do, but are not yet formalised: Release Manager
> and ForrestFriday Coordinator. These first four roles are
> already well-defined.
> 
> There are a number of other roles that are currently being
> done in a haphazard fashion. When we look further, there
> are probably some other roles that we can define.
> 
> PMC Member
> ----------
> This is well-defined in our Guidelines and in the top-level
> ASF docs.
> 
> PMC Chair
> ---------
> This is well-defined in our Guidelines and in the top-level
> ASF docs.
> 
> Release Manager
> ---------------
> This has been a de-facto role. Recently we held a
> discussion to formalise it.
> 
> Tasks are being defined in etc/RELEASE_PROCESS.txt
> 
> ForrestFriday Coordinator
> -------------------------
> This has been a de-facto role. The tasks are defined in
> http://forrest.apache.org/forrest-friday.html
> 
> Issue Tracker Coordinator
> -------------------------
> Add new Components, e.g. for each new plugin.
> Other general Admin tasks.
> Add new committers to the forrest-administrators group.
> Add/enhance Filters.
> Each month get the project to review the outstanding
> major issues that are scheduled for the upcoming release.
> 
> Documentation Coordinator
> -------------------------
> Publish the documentation at least once per week.
> 
> Currently various people make edits to the source files,
> but often the documentation is not generated and published.
> This role is not actually about doing the documentation.
> That should be up to everyone.
> 
> It is very easy:
> cd site-author
> forrest -f publish.xml build
> forrest -f publish.xml deploy
> 
> Subversion Monitor
> ------------------
> Ensure that svn:eol-style settings are appropriate.
> Ensure no line-endings issues.
> Regularly run xml-tidy.
> Regularly run java-tidy.
> 
> There are already some Perl scripts and other tools in
> the "committers" SVN and Forrest SVN.
> 
> Legal Monitor
> -------------
> Regularly run a script which verifies and inserts missing
> license headers to source files.
> 
> Regularly ensure that there are appropriate matching
> licenses to accompany each supporting product that we
> redistribute.
> 
> This should have continual oversight by all PMC Members,
> but the monitoring is something that needs to be done
> regularly, and definitely prior to each release.
> 
> There are already some Perl scripts and other tools in
> the "committers" SVN.
> 
> Developer Role
> --------------
> The above roles are only for PMC Members. How can the
> Developers be involved? That is easy: do the Developer Role.
> 
> Help out with commenting on the Issue Tracker, fixing the
> issues, contributing to discussion, contributing patches,
> turning discussion into clear documentation.

Absolutely, but as I said above, don't you think it a good
Idea for a PMC Member to give those Developers that want it,
A more focused approach, this implies trust, responsibility
And the project as a whole knows that what they are doing
Is being looked after, so others can concentrate elsewhere.

My probably 3 cents worth.

Gav...

> 
> This is incredibly valuable and will enable the project
> to grow. After time, you will probably be elected as
> Committer/PMC Member and when comfortable, can take on
> one of the Project Management Roles.
> 
> --------------------------------------
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.6/324 - Release Date: 25/04/2006




Mime
View raw message