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, one week before the relevant board meeting, according to the reporting schedule at

https://svn.apache.org/repos/private/committers/board/committee-info.txt

Reporting late, or outside of that schedule as mentioned below, does not shift this schedule: if you were supposed to report in January for example, but missed that and reported in February, your next report is still due in April.

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

The content should be committed to the meeting agenda in the board directory in the foundation repository, trying to keep a similar format to the others. This can be found at:

  https://svn.apache.org/repos/private/foundation/board/

Each report should also be sent in plain-text format to board@apache.org with the prefix [REPORT] and the project name in the subject.

Reports submitted in addition to the regular schedule are also welcomed from any PMC, should they have something notable to report or to request feedback on. In this case, the chair may add the report as an attachment to the end of the agenda and create a corresponding comments section as needed.

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.

While the primary audience for the report is the Board of Directors, also consider that the reports are made public and provide a chronological history of your project. It is beneficial to write the report with information that you want your community to know now, and in a way that will provide a helpful history for someone looking over the reports in the future.

You may wish to share the public portions of the report with your project community through the users list or project website.

Points To Cover In Board Reports

  • Briefly describe what your primary software product actually does. [REQUIRED]

    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.

  • Sum up the status of the project in a few sentances

    Starting the report with a paragraph that describe the main things that have happened over the last quarter will help readers understand the key points you want to convey, and will be helpful to those that want to summarize the reports or gather information on what is happening across the foundation quickly. You can then expand on these points in the rest of the report, using the below for guidance.

  • Any issues for the Board?

    If there are any specific issues that the Board should be aware of, or to specifically address, then please call them out.

    It can also be helpful to clarify the converse with a line, "There are no Board-level issues at this time."

  • When did the project last make any releases? [REQUIRED]

    Regular releases are a sign of a healthy project. Reports should list releases made in the past quarter, along with the release date of each.

    NOTE: 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?

    NOTE: If activity is minimal, verify whether or not there are at least three active PMC members who can step in when needed, and include this information in the report.

  • Describe the current plans of the project

    A healthy project will often be working towards a common goal, or have a shared understanding of what is being done next - even if individual contributors have their own "itches". What are the main features being worked on? What releases are planned? Are there any specific efforts or branches of development under way? This doesn't need to be described in technical detail.

    Aside from the report, if there are major announcements planned, the project should get in touch with the Marketing and Publicity Committee at press@apache.org.

    Conversely, if activity is minimal, discuss how the project plans to address that - whether through growing, maintaining in a dormant but available state, or planning towards a move to the Apache Attic.

  • When were the last committers or PMC members elected? [REQUIRED]

    A healthy project tends to regularly add new committers and PMC members.

    The report should indicate the most recent date on which a committer was added and the most recent date on which PMC member was added to your project, whether or not these date(s) were within the last reporting period.

  • 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. IF the PMC has any concerns or perceives a problem with the diversity, then the report should include information on the number of unique organizations currently represented in its PMC and committership.

  • 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?

    If your project's website branding has not been completed (see the checklist), then please include specific plans on how you'll work with the Brand Committee to finalize any remaining items.

    NOTE: basic branding issues should be brought to trademarks@apache.org rather than included in the Board report.

  • Legal issues or questions

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

  • Infrastructure issues or strategic needs

    While the Infrastructure team at infrastructure@apache.org 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, drifted off, or has been superceded by other technologies, 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.

Engaging with the Board about the Report

Project reports are not necessarily a one-directional form of communication. They are also an opportunity to engage with the Board. Project chairs are welcome to attend the Board meeting as a guest and discuss their report. They may also highlight specific issues that they want the Board to consider (either in the report, or by requesting a broader discussion item for the agenda).

Of course, chairs may also take the opportunity to raise any of these discussions on the Board mailing list at any time, inside or outside of their reporting period.

Each month, a Director will be assigned at random as the "Shepherd" for your project report. They will be responsible for following up your report if it is late, describing the report during the meeting if there are significant comments or a lack of approval, and conveying any followup messages or actions after the meeting.

As Directors review the report in the lead up to the meeting, comments may be added into the agenda alongside your report. Project chairs are encouraged to follow these updates (currently by watching for SVN commits), and respond in advance of the meeting when practical.

The current timeline for a board meeting typically follows this pattern:

  1. Near the beginning of the month, the agenda is created and reminders are sent to projects due to report in the current cycle;
  2. Reports are added to the agenda over the following weeks, up until the due date for the meeting;
  3. Directors will review submitted reports at their convenience, and mark them as "pre-approved" if there are no concerns, sometimes adding comments or requests for more information, or editing the content for obvious corrections;
  4. Shepherds are assigned close to the meeting, and become more familiar with those project reports;
  5. A summary of the reports and any comments is sent to the Board mailing list in the 24 hours prior to the meeting;
  6. During the meeting, the Chairman moves quickly through reports that have received 5 or more "pre-approvals" and have no significant comments;
  7. Reports with significant comments, items for discussion, or a lack of pre-approval will be handed over to the shepherd, who will facilitate discussion and recommend any further action;
  8. A summary is sent to all committers after the Board meeting letting them know of the main outcomes;
  9. Any projects that were not approved or missing are added to the reminder list for the subsequent month;
  10. Shepherds will reach out to project chairs with specific action items arising from their reports in the meeting;
  11. Reports are published as part of the minutes, if approved in the subsequent meeting of the Board of Directors.

As you can see, ensuring the report is received on time, includes all necessary details, and has comments addressed greatly enhances the flow of the Board meeting, which needs to cover more than 50 project reports each month, in addition to other business.