Improve project mangement

[fuzzypixelz]

Describe the feature

Context

Currently GitHub projects (V2) are used to manage releases (see Zenoh 1.0.0 release). This is useful because it allows us to manage all eclipse-zenoh repositories in one place ahead of a release. However, manually updating the project is a lot of avoidable clicking. Thus the goal is to automatically add issues related to the next release in the corresponding project.

Constraints

Only issues that are part of the next release and which are opened by a contributor¹ should be added to the corresponding project.

GitHub limitations

1. There is no support for cross-repository milestones.
2. Projects do not support setting custom properties.
3. Pull request templates do not support auto-adding labels like issue templates do. Non-committers cannot add labels to their pull requests. Thus we cannot auto-add pull requests to a project because without labels there is no way to ascertain whether they are part of the next release or not.
4. Projects include "workflows" which can auto-add items to a project but provide no access control (i.e. an issue opened by any user would be added to the project).
5. Issue templates can be configured to auto-add the created issue to a project but (a) the target project names will be hardcoded and (b) only users with write access to eclipse-zenoh can use such a template (which excludes contributors and burdens committers).

Philosophy

A milestone is a project

Because of (1) we resort to using an organization project as a substitute for a cross-repository milestone. These projects should always follow a strict naming scheme, i.e. Zenoh $version release, so they can be reliably identified (see (2)).

All project items are issues

Because of (3) it's difficult to auto-label pull requests, we shall resort to only adding issues to the release project. This is remedied by (a) the fact that issue items added to the release project have a "Linked pull requests" field and (b) as part of this effort, we shall add some form of pull request form enforcement to ensure pull requests have issues linked to them.

Issue labels are either bug, enhancement, new feature or none

Currently, we have two kinds of issue templates: one for reporting bugs and one for requesting features. The latter currently does not include a label, something which should be rectified.

Release project items are identified by a label

We shall use the release issue label to identify issues that are part of the next release. This label would be auto-added upon issue creation using issue templates. Thus we would have two sets of issues templates. One for "freestanding" issues and one for "release-related" issues. This duplication is arguably the least elegant element of this proposal, but GitHub has forced my hand.

Contributors can (indirectly) modify the release project

Today the set of contributors with write access to eclipse-zenoh is too small. At the same time, the circle of all contributors is small enough not to necessitate special access control if it means that project management can be a lot more seamless (i.e. not rely on contributors with write access). At the same time, making someone a contributor by accepting a pull request from them is already gives them additional permissions, such as auto triggering workflows upon opening pull requests.

Use cases

Opening an issue

When a user wishes opens a new issue, they have the option to open a "release-related" issue (either as a bug report or a planned enhancement/new-feature), if a "release-related" issue template is chosen then the opened issue would include, in addition to the bug/enhancement/new feature label, the release label. A workflow configured to trigger upon issue creation would run. If the author is a contributor then the workflow would add the issue in question to the most recent project whose title matches the Zenoh $version release naming scheme. A user who is not necessarily the original issue author would open a pull request whose body contains Closes #123 and thus automatically link the pull request to the issue item on the release project.

Opening a pull request

When a user opens a pull request, a workflow configured to trigger upon pull request creation would run and check if the pull request is linked to an issue. If the pull request does not link to any issue, then the workflow would fail and add a comment suggesting that the author should likely open a corresponding issue, especially if the pull request fixes a bug or adds a new feature. However, merging would not be blocked if no issue is linked.

Caveats

• The Zenoh $version release naming scheme is arguably a hack and should be documented somewhere (perhaps on roadmap, in addition to a description of the process described here as an RFC).
• The TOKEN_BOT_WORKFLOW personal access token doesn't yet allow for managing projects. I opened an issue on the Eclipse Help Desk to remedy this.

Footnotes

1. A contributor is a GitHub user that has authored at least one commit in the repository in question. ↩