# (Proposed) Changes to Project Reporting

At the recent face-to-face in Bratislava, some of the directors proposed some significant changes to the way that projects report.

## Why

There are several problems that we are attempting to address with these changes, or reasons why we believe we should make these changes:

* In discussing the role of the board (see meeting minutes, but, in short, our role is oversight of the Foundation) it became evident that much of what projects report to us have no relation to what we believe is the role of the Board.

* We are not community managers, and attempting be community managers, while not actually being members of those respective projects, can only lead to uninformed tinkering

* We say, everywhere and since the beginning, that we believe in self-governed projects. The way that we ask projects to report, and the way that we respond to those reports, is completely at odds to that claim. More specifically, in resolutions creating projects, we state that we delegate project governance to the PMC. Yet with the way we handle reporting, we make that a lie.

* All rules that we impose on projects should be directly related to our mission - producing software for the public good. However, due to historical accretion, we now have way too many rules. This is, in fact the largest public criticism of the ASF -- that it has too many rules. This is a fair criticism.

* reporter.apache.org generates around half our our report these days. That should be a sign that we are simply creating busy-work for our projects, and asking them to tell us things that we already know. This wastes their time and the time of the board. We should be telling projects this information, not the other way around.

* We are asking board members, and PMC chairs, to do a lot of unnecessary work, that doesn't actually contribute to the mission. If we have an opportunity to reduce that workload, we should do it.

## Proposed Changes

Reports will be reduced to just three questions:

1. Does your project need anything from the Foundation to improve on contributing the our mission of delivering software for the public good?

2. Are there any risks to the sustainability of your project?

3. Are you capable to respond to security issues and perform a release if needed? [conditional]

In theory, a perfect report would be "We're alive and have nothing to report."

To elaborate:

**Are you alive** can be largely figured out from data, and so may not actually need to be asked. In particular, if a project has made a release recently (proposed: In the last 2 quarters) then we don't need to ask any further questions. If they have not, we can look at code repository activity. Failing that, we should ask for a roll call, and ask whether the project could do a release in an emergency security situation.

**What are your risks** asks the project to have some instrospection about what risks or threats face the sustainability of the project. This might include changes to the direction of a significant vendor that contributes to the project, a major contributor leaving the project, or a shift in the technology space what may make the project irrelevant, for example. We will write an appendix that discusses what might be considered risks. A major topic that falls into this question is matters of vendor neutrality.

**What do you need from us** asks the project what, if anything, they would like the Foundation to do, change or provide, to make their project more successful.

We will also specifically encourage PMC members to read what their PMC Chair is submitting, and remind them that any PMC member is always welcome to escallate anything to the Board if they don't feel that their PMC Chair is adequately communicating that message, or that the PMC Chair is not doing their job.

## Automated/Generated Data

Much of the information that we currently ask for in reports, we already know. That is, we have the data, and could, in theory, go find it.

We propose that anything we already "know", we will generate, and send to the project proactively. We will ask them to correct any errors in that data, but if it's all correct, no action actually needs to be taken.

In particular, we (the Board) would send a quarterly report to projects, which would include the following data:

* Releases published in the quarter or the last time a release was done.
* Changes to the Committer and PMC rosters
* Code change metrics
* Issues currently being tracked with operations officers That is, anything that is currently in process with Legal, Trademarks, Security, Fundraising (ie, any targeted donations), Data Privacy, Infrastructure, and Public Affairs.
* Any resolutions, related to the project, that we will be considering in this month's meeting.

During the pilot, we will do this work manually, but eventually we propose that tooling be developed to look up the data that we currently don't have ready access to. This may include some kind of proposed changes to how operations officers track their work - ie, that rather than having to search mailing lists, that open issues be tracked in a ticket tracker somewhere, if that isn't already happening.

## Risks/Costs of Making These Changes

We have identified several risks that may come from making these changes.

* We'll miss stuff. We acknowledge that this may be a false risk. We have been doing things this way for so long that we believe we need to know certain things about a project, which may, in fact, rightfully be something that should be delegated to the PMC, and is not the Board's remit.

* This may create more work for ComDev, since the Board has been acting as community managers for so long. However, we acknowledge that this isn't actually the role of the board, is often unwelcome, and is rightfully delegated to the PMC. We should encourage projects to have a community member who serves as a community manager. This is an opportuity for recruiting that position. We note that several projects already have someone explicitly in this role.

* Providing information to the project will require tooling that does not yet exist and would need to be developed. During the pilot period, we'll need to generate this manually. Additionally, some of the officers do not track their tasks in a ticketing system, or other easily extractable format, requiring scans of mailing list for active tasks. We may need to change officers' workflows to accommodate this kind of reporting.

## Proposed Timeline

This is a big change with many moving prts. We plan to do this gradually, with a pilot/experimentation phase.

We plan to invite several projects to participate in this experiment. (If you want your project to be a test subject, please speak up!) These projects will be asked to change how they report, hopefully for the next few board meetings (July, August, September) and then we'll evaluate the results and iterate on the requirements after that.