site-author/content/xdocs/roles.xml - forrest - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!--
   Licensed to the Apache Software Foundation (ASF) under one or more
   contributor license agreements.  See the NOTICE file distributed with
   this work for additional information regarding copyright ownership.
   The ASF licenses this file to You under the Apache License, Version 2.0
   (the "License"); you may not use this file except in compliance with
   the License.  You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
 -->
 <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
   "http://forrest.apache.org/dtd/document-v20.dtd">
 <document>
   <header>
     <title>Project roles</title>
   </header>
   <body>
     <section id="overview">
       <title>Overview</title>
       <p>
         There are many tasks that need to be done to keep the project flowing.
         With the tasks being well-defined, the hope is that various people will
         be able to assist to carry out the role and so not rely on a couple of
         individuals to do all the work.
       </p>
       <p>
         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".
       </p>
       <p>
         This is not intended to put pressure on people to force them to do work
         nor "pull their weight". If they do not manage to do a task, then
         someone else will be able to do it. Of course, shared load means a
         healthy project.
       </p>
       <p>
         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.
       </p>
       <p>
         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 who is primarily
         doing that role will notice that there can be improvements to how they
         are doing it.
       </p>
       <p>
         If a person is dissatisfied with the way a particular role is being done
         then find a way to offer constructive criticism, perhaps by assisting or
         by enhancing the role documentation.
       </p>
       <p>
         Most of the roles (except of course the Developer role) can only be
         carried out by PMC members because commit access is required.
       </p>
     </section>
     <section id="roles">
       <title>The roles</title>
       <p>
         These are the main roles, including the obvious ones. There are probably
         other roles that need to be defined also. Each role should have some
         continually enhanced documentation about it, so that any person can do
         the tasks.
       </p>
       <section id="pmc-member">
         <title>PMC Member</title>
         <p>
           This is well-defined in our <a href="site:guidelines">project
           guidelines</a> and in the top-level ASF docs.
         </p>
       </section>
       <section id="pmc-chair">
         <title>PMC Chair</title>
         <p>
           This is well-defined in our <a href="site:guidelines">project
           guidelines</a> and in the top-level ASF docs.
         </p>
       </section>
       <section id="release-manager">
         <title>Release Manager</title>
         <p>
           Tasks are defined in <a href="site:howToRelease">How to Release
           Forrest</a>
         </p>
         <p>
           Only one person can do this role, although other people can assist.
           There is a lot of knowledge invested in this role. Document it as much
           as possible.
         </p>
       </section>
       <section id="forrest-friday-coordinator">
         <title>ForrestFriday Coordinator</title>
         <p>
           The tasks are defined in
           <a href="site:forrest-friday">ForrestFriday</a>.
         </p>
         <p>
           Each month someone needs to co-ordinate the IRC session and be the
           main channel operator, maintain the logfile and commit it to the
           events SVN.
         </p>
         <p>
           Ensure that the session is summarised.
         </p>
         <p>
           This role can possibly be done by someone who is not a committer.
           However, a logfile and summary need to be committed to SVN.
         </p>
       </section>
       <section id="issue-tracker-coordinator">
         <title>Issue Tracker Coordinator</title>
         <p>
           Add new Components, e.g. for each new plugin.
         </p>
         <p>
           Other general Admin tasks.
         </p>
         <p>
           Add new committers to the forrest-administrators group.
         </p>
         <p>
           Add/enhance <a href="site:bugs">Filters</a>.
         </p>
         <p>
           Review issues to ensure that they are properly categorised. This is
           best done as soon as a new issue comes in.
         </p>
         <p>
           Review the list of unscheduled issues.
         </p>
         <p>
           Each month get the project to review the outstanding major issues that
           are scheduled for the upcoming release.
         </p>
       </section>
       <section id="documentation-coordinator">
         <title>Documentation Coordinator</title>
         <p>
           Publish the documentation at least once per week.
         </p>
         <p>
           Various people make edits to the source files, but often the
           documentation is not generated and published. Also people add new
           entries to site-author/status.xml but the changes.html needs to be
           regularly generated from it.
         </p>
         <p>
           This role is not actually about doing the documentation. That should
           be up to everyone.
         </p>
         <p>
           Generating and publishing the main docs is very easy using a local
           forrestbot: See <a href="site:howToPublishDocs">How to publish Forrest
           documentation</a>.
         </p>
       </section>
       <section id="subversion-monitor">
         <title>Subversion Monitor</title>
         <p>
           Ensure that svn:eol-style settings are "native" for all text files.
         </p>
         <p>
           Ensure no line-endings issues.
         </p>
         <p>
           Regularly run xml-tidy. (Not yet ready.)
         </p>
         <p>
           Regularly run java-tidy. (Not yet ready.)
         </p>
         <p>
           There are already some Perl scripts and other tools in the
           "<a href="https://svn.apache.org/repos/private/committers">committers</a>"
           SVN in the "tools" directory.
         </p>
       </section>
       <section id="legal-monitor">
         <title>Legal Monitor</title>
         <p>
           Regularly run a script which verifies and inserts missing license
           headers to source files.
         </p>
         <p>
           Regularly ensure that there are appropriate matching licenses to
           accompany each supporting product that we redistribute.
         </p>
         <p>
           This should have continual oversight by the PMC as a whole, but the
           monitoring is something that needs to be done regularly, and
           definitely prior to each release.
         </p>
         <p>
           There are already some Perl scripts and other tools in the
           "<a href="https://svn.apache.org/repos/private/committers">committers</a>"
           SVN in the "tools" and "relicense/src/perl" directories.
         </p>
       </section>
       <section id="developer">
         <title>Developer</title>
         <p>
           The above roles are only for PMC Members. How can the Developers be
           involved? That is easy: do the Developer Role.
         </p>
         <p>
           Help out with commenting on the Issue Tracker, fixing the issues,
           contributing to discussion, contributing patches, turning discussion
           into clear documentation.
         </p>
         <p>
           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.
         </p>
       </section>
     </section>
   </body>
 </document>
	<?xml version="1.0" encoding="UTF-8"?>
	<!--
	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	The ASF licenses this file to You under the Apache License, Version 2.0
	(the "License"); you may not use this file except in compliance with
	the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->
	<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
	"http://forrest.apache.org/dtd/document-v20.dtd">
	<document>
	<header>
	<title>Project roles</title>
	</header>
	<body>
	<section id="overview">
	<title>Overview</title>
	<p>
	There are many tasks that need to be done to keep the project flowing.
	With the tasks being well-defined, the hope is that various people will
	be able to assist to carry out the role and so not rely on a couple of
	individuals to do all the work.
	</p>
	<p>
	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".
	</p>
	<p>
	This is not intended to put pressure on people to force them to do work
	nor "pull their weight". If they do not manage to do a task, then
	someone else will be able to do it. Of course, shared load means a
	healthy project.
	</p>
	<p>
	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.
	</p>
	<p>
	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 who is primarily
	doing that role will notice that there can be improvements to how they
	are doing it.
	</p>
	<p>
	If a person is dissatisfied with the way a particular role is being done
	then find a way to offer constructive criticism, perhaps by assisting or
	by enhancing the role documentation.
	</p>
	<p>
	Most of the roles (except of course the Developer role) can only be
	carried out by PMC members because commit access is required.
	</p>
	</section>
	<section id="roles">
	<title>The roles</title>
	<p>
	These are the main roles, including the obvious ones. There are probably
	other roles that need to be defined also. Each role should have some
	continually enhanced documentation about it, so that any person can do
	the tasks.
	</p>
	<section id="pmc-member">
	<title>PMC Member</title>
	<p>
	This is well-defined in our <a href="site:guidelines">project
	guidelines</a> and in the top-level ASF docs.
	</p>
	</section>
	<section id="pmc-chair">
	<title>PMC Chair</title>
	<p>
	This is well-defined in our <a href="site:guidelines">project
	guidelines</a> and in the top-level ASF docs.
	</p>
	</section>
	<section id="release-manager">
	<title>Release Manager</title>
	<p>
	Tasks are defined in <a href="site:howToRelease">How to Release
	Forrest</a>
	</p>
	<p>
	Only one person can do this role, although other people can assist.
	There is a lot of knowledge invested in this role. Document it as much
	as possible.
	</p>
	</section>
	<section id="forrest-friday-coordinator">
	<title>ForrestFriday Coordinator</title>
	<p>
	The tasks are defined in
	<a href="site:forrest-friday">ForrestFriday</a>.
	</p>
	<p>
	Each month someone needs to co-ordinate the IRC session and be the
	main channel operator, maintain the logfile and commit it to the
	events SVN.
	</p>
	<p>
	Ensure that the session is summarised.
	</p>
	<p>
	This role can possibly be done by someone who is not a committer.
	However, a logfile and summary need to be committed to SVN.
	</p>
	</section>
	<section id="issue-tracker-coordinator">
	<title>Issue Tracker Coordinator</title>
	<p>
	Add new Components, e.g. for each new plugin.
	</p>
	<p>
	Other general Admin tasks.
	</p>
	<p>
	Add new committers to the forrest-administrators group.
	</p>
	<p>
	Add/enhance <a href="site:bugs">Filters</a>.
	</p>
	<p>
	Review issues to ensure that they are properly categorised. This is
	best done as soon as a new issue comes in.
	</p>
	<p>
	Review the list of unscheduled issues.
	</p>
	<p>
	Each month get the project to review the outstanding major issues that
	are scheduled for the upcoming release.
	</p>
	</section>
	<section id="documentation-coordinator">
	<title>Documentation Coordinator</title>
	<p>
	Publish the documentation at least once per week.
	</p>
	<p>
	Various people make edits to the source files, but often the
	documentation is not generated and published. Also people add new
	entries to site-author/status.xml but the changes.html needs to be
	regularly generated from it.
	</p>
	<p>
	This role is not actually about doing the documentation. That should
	be up to everyone.
	</p>
	<p>
	Generating and publishing the main docs is very easy using a local
	forrestbot: See <a href="site:howToPublishDocs">How to publish Forrest
	documentation</a>.
	</p>
	</section>
	<section id="subversion-monitor">
	<title>Subversion Monitor</title>
	<p>
	Ensure that svn:eol-style settings are "native" for all text files.
	</p>
	<p>
	Ensure no line-endings issues.
	</p>
	<p>
	Regularly run xml-tidy. (Not yet ready.)
	</p>
	<p>
	Regularly run java-tidy. (Not yet ready.)
	</p>
	<p>
	There are already some Perl scripts and other tools in the
	"<a href="https://svn.apache.org/repos/private/committers">committers</a>"
	SVN in the "tools" directory.
	</p>
	</section>
	<section id="legal-monitor">
	<title>Legal Monitor</title>
	<p>
	Regularly run a script which verifies and inserts missing license
	headers to source files.
	</p>
	<p>
	Regularly ensure that there are appropriate matching licenses to
	accompany each supporting product that we redistribute.
	</p>
	<p>
	This should have continual oversight by the PMC as a whole, but the
	monitoring is something that needs to be done regularly, and
	definitely prior to each release.
	</p>
	<p>
	There are already some Perl scripts and other tools in the
	"<a href="https://svn.apache.org/repos/private/committers">committers</a>"
	SVN in the "tools" and "relicense/src/perl" directories.
	</p>
	</section>
	<section id="developer">
	<title>Developer</title>
	<p>
	The above roles are only for PMC Members. How can the Developers be
	involved? That is easy: do the Developer Role.
	</p>
	<p>
	Help out with commenting on the Issue Tracker, fixing the issues,
	contributing to discussion, contributing patches, turning discussion
	into clear documentation.
	</p>
	<p>
	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.
	</p>
	</section>
	</section>
	</body>
	</document>