Experimental repositories¶
Apache Arrow has an explicit policy over developing experimental repositories in the context of rules for revolutionaries.
The main motivation for this policy is to offer a lightweight mechanism to conduct experimental work, with the necessary creative freedom, within the ASF and the Apache Arrow governance model. This policy allows committers to work on new repositories, as they offer many important tools to manage it (e.g. github issues, “watch”, “github stars” to measure overall interest).
Process¶
A committer may initiate experimental work by creating a separate git repository within the Apache Arrow (e.g. via selfserve) and announcing it on the mailing list, together with its goals, and a link to the newly created repository.
The committer must initiate an email thread with the sole purpose of presenting updates to the community about the status of the repo.
There must not be official releases from the repository.
Any decision to make the experimental repo official in any way, whether by merging or migrating, must be discussed and voted on in the mailing list.
The committer is responsible for managing issues, documentation, CI of the repository, including licensing checks.
The committer decides when the repository is archived.
Repository management¶
The repository must be under
apache/
The repository’s name must be prefixed by
arrow-experimental-
The committer has full permissions over the repository (within possible in ASF)
Push / merge permissions must only be granted to Apache Arrow committers
Development process¶
The repository must follow the ASF requirements about 3rd party code.
The committer decides how to manage issues, PRs, etc.
Divergences¶
If any of the “must” above fails to materialize and no correction measure is taken by the committer upon request, the PMC should take ownership and decide what to do.