| <?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 tasks</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 tasks 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 |
| tasks". |
| </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 tasks are not too onerous. For example, for |
| the "Documentation Coordination", 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 task 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 task, the better. Perhaps the person who is primarily |
| doing that task 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 task is being done |
| then find a way to offer constructive criticism, perhaps by assisting or |
| by enhancing the task documentation. |
| </p> |
| <p> |
| Most of the tasks (except of course the Developer tasks) can only be |
| carried out by PMC members because commit access is required. |
| </p> |
| </section> |
| <section id="tasks"> |
| <title>The tasks</title> |
| <p> |
| These are the main tasks, including the obvious ones. There are probably |
| other tasks that need to be defined also. Each task 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 task, although other people can assist. |
| There is a lot of knowledge invested in this RM role. Document it as much |
| as possible. |
| </p> |
| </section> |
| <section id="forrest-friday-coordination"> |
| <title>ForrestFriday Coordination</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 task 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-coordination"> |
| <title>Issue Tracker Coordination</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-coordination"> |
| <title>Documentation Coordination</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 task 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="ci-monitoring"> |
| <title>Continuous Integration Monitoring</title> |
| <p> |
| We mainly use Apache Gump, which conducts |
| <a href="site:gump-forrest">various jobs</a> for us. |
| </p> |
| <p> |
| Monitor the Forrest dev mail list, where Gump sends our notifications. |
| Attend to Forrest-related issues. Issues may arise from our dependencies |
| - Gump will encourage us to help to fix those. |
| </p> |
| <p> |
| Enhance and extend the jobs that Gump performs for us. |
| </p> |
| <p> |
| We also have the ASF |
| <a href="http://ci.apache.org/buildbot.html">Buildbot</a> |
| which just runs our RAT report (which Gump also does). |
| See some notes <a href="#legal-monitoring">below</a> |
| in the Legal Monitoring section. |
| </p> |
| </section> |
| <section id="subversion-monitoring"> |
| <title>Subversion Monitoring</title> |
| <p> |
| The issue of whitespace is important in projects which have developers |
| on both Windows and UNIX-based operating systems. The unnecessary |
| differences obscure the real changes and so make it difficult for |
| people to be aware. |
| </p> |
| <p> |
| Ensure that svn:eol-style settings are "native" for all text files. |
| Encourage people to properly |
| <a href="http://www.apache.org/dev/version-control.html#https-svn-config">configure</a> |
| their SVN client. |
| Detect such issues using a script like |
| <a href="https://svn.apache.org/repos/private/committers/tools/report_svn_text.pl">committers/tools/report_svn_text.pl</a> |
| and see also some tips in |
| <a href="https://issues.apache.org/jira/browse/FOR-124">FOR-124</a>. |
| </p> |
| <p> |
| Ensure no line-endings issues. This is coupled with the abovementioned |
| "svn:eol-style" issue. |
| Detect such issues using a script like |
| <a href="https://svn.apache.org/repos/private/committers/tools/find_carriage_returns.sh">committers/tools/find_carriage_returns.sh</a> |
| </p> |
| <p> |
| Regularly tidy the whitespace in xml files. |
| See the script |
| <a href="http://svn.apache.org/repos/asf/forrest/trunk/etc/tidy-xml.pl">$FORREST_HOME/etc/tidy-xml.pl</a> |
| and the |
| <a href="http://svn.apache.org/repos/asf/forrest/trunk/etc/tidy-config.txt">$FORREST_HOME/etc/tidy-config.txt</a> configuration file. |
| This is best done as part of the release process, when everyone should |
| have already committed any outstanding changes. With such an operation, |
| there is a high chance of conflicts. |
| See also some tips in |
| <a href="https://issues.apache.org/jira/browse/FOR-644">FOR-644</a>. |
| </p> |
| <p> |
| Regularly run java-tidy. (Not yet ready.) |
| </p> |
| </section> |
| <section id="legal-monitoring"> |
| <title>Legal Monitoring</title> |
| <p> |
| Regularly run a script which verifies and inserts missing license |
| headers to source files. Review the output and fix issues. |
| For example: |
| <a href="https://svn.apache.org/repos/private/committers/relicense/src/perl/">committers/relicense/src/perl/</a> |
| and other tools at |
| <a href="https://svn.apache.org/repos/private/committers/tools/">committers/tools/</a> |
| and |
| <a href="http://creadur.apache.org/rat/">Apache RAT</a> |
| and some other suggestions at |
| <a href="http://labs.apache.org/">Apache Labs</a>. |
| See also some tips in |
| <a href="https://issues.apache.org/jira/browse/FOR-855">FOR-855</a> |
| and |
| <a href="https://issues.apache.org/jira/browse/FOR-123">FOR-123</a>. |
| Also see $FORREST_HOME/etc/relicense.txt and |
| $FORREST_HOME/etc/relicense-avoid.txt files. |
| </p> |
| <p> |
| RAT is automatically run on our sources. See the reports via |
| <a href="site:gump-forrest">Gump</a> and |
| <a href="http://ci.apache.org/projects/forrest/rat-output.html">Buildbot</a>. |
| We are not being notified about |
| <a href="https://ci.apache.org/builders/forrest-trunk">Buildbot</a> |
| errors, so need to look. |
| </p> |
| <p> |
| Regularly ensure that there are appropriate matching licenses to |
| accompany each supporting product that we redistribute. |
| (Use the filename pattern: product-version[.-]license.txt or uppercase.) |
| </p> |
| <p> |
| For each such license, also ensure that it is referred to in |
| $FORREST_HOME/LICENSE.txt file. If their license required attribution, |
| then add to $FORREST_HOME/NOTICE.txt file. Also replicate any NOTICE |
| which accompanies a supporting product. |
| See <a href="https://issues.apache.org/jira/browse/FOR-857">FOR-857</a>. |
| </p> |
| <p> |
| See some guidelines at |
| <a href="http://www.apache.org/dev/#licenses">ASF Legal</a>. |
| </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> |
| </section> |
| <section id="developer"> |
| <title>Developer</title> |
| <p> |
| The above tasks are only for PMC Members. How can any Developer be |
| involved? That is easy: do the Developer tasks. |
| </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 tasks. |
| </p> |
| </section> |
| </section> |
| </body> |
| </document> |
