Project Board Reporting Guidelines

The Board of Directors oversees the official affairs of all Apache projects by reviewing quarterly reports from each Project Management Committee (PMC) and from the Apache Incubator, which reports on the status of its Podlings.
While projects are expected to manage their technical affairs independently, the Board is responsible for ensuring that projects continue to operate as healthy, community- and consensus-driven projects that support our mission.

The chair of each PMC is responsible for submitting the report for their project on a quarterly basis, well before the relevant board meeting (ask on the board@ mailing list if unsure about exactly when).

While in most many cases the chair works with other PMC members to complete the project, the report is the chair's responsibility to complete and submit.

These guidelines are not a template; projects should not simply copy and paste these bullets into their reports. Rather, these are the topics that the Board wants to hear about to be able to evaluate the health and status of our projects. Not all topics will be pertinent to every report; however the chair should consider all of these quesitons when writing a report.

Points To Cover In Board Reports

  • Briefly describe what your primary software product actually does.

    For example:
The Apache Xerces XML parsing library is easily configurable 
and compliant with current standards.
Note that this description should be similar to the basic 
trademark description your main website uses.
See [Brand Naming and Description][1].

  • When did the project last make any releases?

    Regular releases are a sign of a healthy project.  Reports should list 
releases made in the past quarter.  If no releases were made, list the 
date of the most recent prior release, so that the board can determine 
how long it has been since the project has made a release.

  • Describe the overall activity in the project over the past quarter.

    Help the board evaluate the activity and health of the project by 
discussing briefly how active the user and developer lists are.  Are user 
questions being answered?  Is there new development happening, or just 
bugfixes?  Are emails regularly read and responded to?

  • Are there any changes in Committers or PMC members?

    A healthy project tends to regularly add new committers and PMC members.  
The report should name new committers and PMC members added in the past 
quarter.  If none were added the report should name the date that the 
last committer and PMC member were added.

  • PMC and committer diversity

    A healthy project should survive the departure of any single contributor 
or employer of contributors.  Healthy projects also serve needs of many 
parties.  Thus the ASF prefers that projects have diverse PMCs and 
committerships.  Report should include information on  
the number of unique organizations currently represented in its PMC 
and committership if there are any current or potential concerns about 
diversity.

  • Project branding or naming issues, either in the project or externally.

     A project's brand - or name and logo - are an important way to identify 
 Apache projects, and a key way that new users can become contributors.  Is 
 the project using its brand consistently?  Are there third parties that 
 are using the project's name, logo, or good reputation for their own 
 ends?  (Note that basic branding issues should be brought to trademarks@).
See the [checklist][2] for more info.

  • Legal issues or questions

     While the Legal Affairs Committee at legal-internal@ should handle any 
 legal issues, be sure to discuss any that occour in your board report.

  • Infrastructure issues or strategic needs

     While the Infra team at infrastructure@ handles the detail of providing 
 needed services to our projects, feel free to include any concerns or 
 strategic suggestions or requests in your board reports.

Things Not To Put In Reports

  • Do not let commercial activity related to a project dominate a report.

    Apache projects are managed by the controlling PMC - not by any third 
party or outside organization.  Project reports should be about the project, 
and should not discuss outside organization's efforts unless they 
are directly related to the health of the project.

  • Do not include private matters in a report without clearly marking them (see below)

  • Do not use non-Apache URL shorteners.

    If you have a long URL you wish to include in your report, please use (only)
the https://s.apache.org/ URL shortener to provide a shorter link.  The use 
of external URL shorteners is problematic since Apache cannot control 
their future longevity.

Private information

Occasionally a project may need to report something privately to the board, but will not want the information to be published in public minutes.

Such information is welcome in your report, but please include it within <private> and </private> markers so we know what to omit from the public minutes.

The next level of privacy, is information that is to be shared only privately with the board members. For that, feel free to write directly to a board member who will relay the information to the board.

Other Considerations For Reports

Project reports are the key way to let the board know about the status and health of your project. With the diversity of projects at Apache, these guidelines can't cover all situations. Feel free to include any additional information in your reports that you think is important about your project.

In particular, if there are any "trouble spots" - even potential ones - that the chair or other members of the PMC see in the project, be sure to include a note about them in your board reports.

Finally, if you find yourself with a project that doesn't seem like it has enough activity to create much of a report, then be sure to report that fact. A healthy project should be aware if they are headed for the Apache Attic.
Moving to the Attic isn't failure; it's simply recognizing that the project may have matured or drifted off, and we should recognize that fact.

The Board relies on reports from project chairs to be able to understand the status and health of projects. If the Board cannot get a strong feeling about how your project is doing, then we will be contacting you for a follow-up report in the near future.