So I had a look at Apache Airflow which is a top level project that does use Github’s tools more extensively than other projects. They use GitHub discussions (see https://github.com/apache/airflow/discussions) as the primary method of communication rather than the dev/user mailing list (see https://lists.apache.org/[email protected]). Their dev mailing list appears to be exclusively for formal votes on releases, announcement of releases as well as AIP’s (DISCUSS/VOTE). Likewise their users mailing list (see https://lists.apache.org/[email protected]) is largely vacant apart from announcements of new versions of Apache Airflow, as a replacement they also use GitHub discussions, specifically Q&A and general (see https://github.com/apache/airflow/discussions/categories/q-a and https://github.com/apache/airflow/discussions/categories/general respectively).
Apache Airflow has AIP (Airflow Improvement Proposal) which are listed on the Apache Wiki (see https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals) and they do create [DISCUSS]/[VOTE] proposals for the AIP’s on their dev mailing list however the community also does use informal polling via GitHub poll discussions (see https://github.com/apache/airflow/discussions/24855 as an example albeit its the only one) to gauge community on questions with Github poll’s in a similar way that Pekko did. For pull requests they require a single GitHub approval from the committer organisation rather than two (https://github.com/apache/airflow/pull/27326 is an example of a PR that was merged with a single approval). Not sure what the distinction here is, but at least for Pekko I would say that we also require 2 votes since that is also what Akka has/had (note this needs to be decided/voted upon). Regards -- Matthew de Detrich Aiven Deutschland GmbH Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen m: +491603708037 w: aiven.io e: [email protected] On 27. Oct 2022, 17:18 +0200, Claude Warren, Jr <[email protected]>, wrote: > The Apache process is mostly up to the group running the project. However > there are a few things that have to be done to satisfy the requirements of > legal and the board. > > > - must be reviewed and approved by at least two committers who are not > the developer(s). > > - must be voted on in the development list using the code modifications > process documented in the Apache voting process document > > These items do seem redundant. However, the first is within the pull > request itself. Two new eyes to look at the code. The second is a record > on the mailing list that it was accepted. > > There are different levels of preservation associated with each. Apache > considers the mailing list to be the repository of truth: It it isn't on > the mailing list it didn't happen. > Git (where the pull requests and such occur) can be and often are rewritten > meaning that some history can be lost or obfuscated. > > I put those up so we can have these discussions. > > Your comment about a continuum is a valid one. Please write up your > change as a proposal. Specify the section numbers from the original > document. I think you are talking about 2.3.b and 2.3.c > > > > On Thu, Oct 27, 2022 at 9:34 AM Johannes Rudolph <[email protected]> > wrote: > > > Thanks everyone for setting this project up! > > > > Please pardon my ignorance of the details of common Apache processes, > > I guess this proposal is modeled after existing Apache projects. > > > > The process states: > > > > > All pull requests for code changes (e.g. changes that modify the code > > execution) > > > > > > - must be associated with an issue. > > > - must be reviewed and approved by at least two committers who are not > > the developer(s). > > > - must be voted on in the development list using the code modifications > > process documented in the Apache voting process document > > > > The latter two points seem somewhat redundant. What's the rationale > > behind having this double process of gathering reviewing approvals > > first and then another vote on the mailing list? How does that usually > > work in practice? > > > > I understand (and agree) that the dev mailing list should be the > > definitive place to gather information and decide on development, so > > it's nice that you can just follow it and will never miss something. > > On the other hand, there's a continuum between trivial documentation > > changes and a significant functional code change. E.g. there are > > non-trivial code changes that are still small and might suffer from > > the extra overhead of the full process of review + vote. > > > > I'd propose to make review approvals on Github PRs binding in general > > but allow reviewers to promote a change to a discussion (+ vote) on > > the mailing list if deemed necessary (i.e. make the third point > > optional as long as no one objects to it). > > > > Are there existing Apache Projects that we could take as an example? > > (E.g. Kafka? > > https://cwiki.apache.org/confluence/display/KAFKA/Contributing+Code+Changes > > ) > > > > Thanks, > > Johannes > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > >
