GitHub's Issues is the first tab I hit on any project I view on GitHub, going straight for the search bar in order to see if my issue was discussed before. I hope we'll use GitHub Issues for our project management, as it lowers the barrier for participating. Everything else is a nice to have, but we can also KISS, YAGNI, etc.
For improvement proposals, if we need serious documentation, we can go with whatever ASF-approved way of documentation we have, but that should preferably yield a link in a GitHub Issue, because that's where people like me go to search. For proposals requiring documentation, PIPs, we could also initialize another GitHub repository, such that we can have PRs. But, using an Apache's Confluent is probably OK, as long as it's being linked from a GitHub Issue. Whatever works to get the process going. On Thu, Nov 3, 2022, at 08:26, Matthew Benedict de Detrich wrote: > Ah I wasn’t aware of that, if there is already precedent then that of > course changes things. If we are going the GitHub route I would > personally prefer Github wiki since it seems like the natural tool for > this (issues has practical problems) but that may be pushing it too far. > > -- > 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 3. Nov 2022 at 07:20 +0100, Greg Methvin <[email protected]>, wrote: >> I know Apache Pulsar uses GitHub issues: >> https://github.com/apache/pulsar/wiki#pulsar-improvement-proposals. They >> may be a special exception though. >> >> I don't have a strong preference either way though. GitHub makes it >> slightly easier for people to submit a PIP since they don't need an account >> on Confluence, but in practice I suppose most people submitting PIPs will >> be Apache committers anyway. >> >> On Wed, Nov 2, 2022 at 10:54 PM Matthew Benedict de Detrich >> <[email protected]> wrote: >> >> > Regarding creating Pekko Improvement Proposals, AFAIK we have to follow an >> > already existing process which is creating a wiki page on the Apache >> > confluent page, i.e. see the Apache Airflow Page as an example ( >> > https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals >> > ). >> > >> > I am not aware of any other approved way of doing it. >> > >> > -- >> > 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 3. Nov 2022 at 02:47 +0100, Greg Methvin <[email protected]>, wrote: >> > > +1 on all these suggestions. >> > > >> > > We also have to decide on the details of how PIP should work. My rough >> > idea >> > > is: >> > > 1. Create a PIP ticket on GitHub using a predefined PIP template. >> > > 2. Start a discussion on the mailing list referencing the ticket. >> > > 3. Once a consensus is reached, perform a vote using the Apache voting >> > > process. >> > > 4. If the PIP passes, the author and other contributors create PRs >> > > referencing the original PIP ticket on GitHub. Code review follows the >> > > normal code review process. >> > > >> > > I'm thinking we probably should have an entirely separate PIP section in >> > > our process doc? >> > > >> > > On Wed, Nov 2, 2022 at 7:05 AM Claude Warren, Jr >> > > <[email protected]> wrote: >> > > >> > > > I suggest changing "Examples of such issues include:" to "Examples of >> > such >> > > > issues include, but are not limited to:" >> > > > >> > > > On Wed, Nov 2, 2022 at 1:46 PM Matthew Benedict de Detrich >> > > > <[email protected]> wrote: >> > > > >> > > > > > New point 3 (pushing down existing point 3 to 4, etc.) >> > > > > 3. For major/breaking changes, we require that a Pekko Improvement >> > > > > Process (PIP) proposal is submitted on the dev mailing list before a >> > > > > PR is made. After allowing some time for discussion, a vote will be >> > > > > required on the dev mailing list using the code modifications process >> > > > > documented in the Apache voting process document. When we have >> > general >> > > > > agreement on the proposal, we can proceed to submitting PRs. Examples >> > > > > of such issues include: >> > > > > a. new Pekko features/libraries >> > > > > b. changes to public APIs >> > > > > c. significant upgrades to jar dependencies >> > > > > d. changes to wire protocol >> > > > > e. large changes across many Pekko components >> > > > > >> > > > > My suggestion would be to further equivocate this so that its more >> > > > > accurate. For example, for both the contributors and users of Akka >> > (and >> > > > now >> > > > > Pekko), breaking binary compatibility is something that was checked >> > with >> > > > > sbt-mima (see https://github.com/lightbend/mima). Furthermore, >> > forwards >> > > > > breaking changes that weren’t major was actually allowed in with >> > just a >> > > > > standard basic review (which also involved putting in ProblemFilters >> > into >> > > > > sbt-mima, see the currently existing mina-filters folders). Such >> > changes >> > > > > were also sometimes put behind the @ApiMayChange annotation if there >> > was >> > > > a >> > > > > chance that the API may change future because but the merits of >> > adding in >> > > > > the change outweighed perfect stability, this was quite a common >> > > > occurrence >> > > > > in fast moving modules such as akka (and now pekko) streams >> > > > > >> > > > > There is also another @InternalApi annotation whereby you can break >> > > > > anything you want and is only meant for internal use. >> > > > > >> > > > > It would be good to also add these details into the process >> > document. I >> > > > > think there is a lot of merit in being quite precise here for what >> > > > requires >> > > > > a Pekko Improvement Proposal because we can run the risk of making >> > it to >> > > > > budersome to contribute to Pekko if the keep on throwing the “this >> > needs >> > > > a >> > > > > Pekko Improvement Proposal” due to unclear rules. >> > > > > >> > > > > -- >> > > > > 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 2. Nov 2022, 14:34 +0100, PJ Fanning <[email protected]>, >> > wrote: >> > > > > > Can I suggest these amendments to >> > > > > > https://cwiki.apache.org/confluence/display/PEKKO/Processes ? I'm >> > > > > > happy for any of these proposed changes to be adjusted or discussed >> > > > > > further. >> > > > > > >> > > > > > Change >> > > > > > 1. Defects are recorded in the git issue for the associated Pekko >> > > > module. >> > > > > > to >> > > > > > 1. Defects are recorded in the Github issue tracker for the >> > associated >> > > > > > Pekko module. >> > > > > > >> > > > > > New point 3 (pushing down existing point 3 to 4, etc.) >> > > > > > 3. For major/breaking changes, we require that a Pekko Improvement >> > > > > > Process (PIP) proposal is submitted on the dev mailing list before >> > a >> > > > > > PR is made. After allowing some time for discussion, a vote will be >> > > > > > required on the dev mailing list using the code modifications >> > process >> > > > > > documented in the Apache voting process document. When we have >> > general >> > > > > > agreement on the proposal, we can proceed to submitting PRs. >> > Examples >> > > > > > of such issues include: >> > > > > > a. new Pekko features/libraries >> > > > > > b. changes to public APIs >> > > > > > c. significant upgrades to jar dependencies >> > > > > > d. changes to wire protocol >> > > > > > e. large changes across many Pekko components >> > > > > > >> > > > > > Change 3c (which becomes 4c because of new point 3 above) >> > > > > > >> > > > > > c. if a Pekko committer requests that the PR changes should be >> > > > > > discussed more widely, the changes should be discussed on the dev >> > > > > > mailing list and voted on using the code modifications process >> > > > > > documented in the Apache voting process document. >> > > > > > >> > > > > > Change 5c (which becomes 6c because of new point 3 above) >> > > > > > >> > > > > > c. if a Pekko committer requests that the PR changes should be >> > > > > > discussed more widely, the changes should be discussed on the dev >> > > > > > mailing list and voted on using the code modifications process >> > > > > > documented in the Apache voting process document. >> > > > > > >> > > > > > On Thu, 27 Oct 2022 at 09:55, Claude Warren, Jr >> > > > > > <[email protected]> wrote: >> > > > > > > >> > > > > > > One of the first things this team needs to do is to decide how >> > > > > development >> > > > > > > will be done. I have drafted a process document to kick this >> > > > discussion >> > > > > > > off. >> > > > > > > >> > > > > > > The draft document is found at >> > > > > > > https://cwiki.apache.org/confluence/display/PEKKO/Processes >> > > > > > > >> > > > > > > For purposes of this discussion: >> > > > > > > >> > > > > > > 1. No changes will be made until a code modification vote is >> > taken. >> > > > See >> > > > > > > https://www.apache.org/foundation/voting.html for requirements. >> > For >> > > > > > > those of you who have edit access to the document please do not >> > > > change >> > > > > it >> > > > > > > until we have a vote. >> > > > > > > 2. Committers and Mentors have binding votes. All other votes are >> > > > > > > advisory. >> > > > > > > 3. Discussions of proposed changes must be posted to the >> > > > > > > [email protected] mailing list and the subject should be >> > prefixed >> > > > > > > with "[DISCUSS]". >> > > > > > > 4. Calls for votes on the proposed changes must be made on the >> > > > > > > [email protected] mailing list and the subject should be >> > prefixed >> > > > > > > with "[VOTE]" to make it easy to identify. >> > > > > > > 5. Results of votes will be published on the dev mailing list >> > with >> > > > > > > "[RESULT]" prefixing the subject. >> > > > > > > 6. A vote to accept the document may be taken once all proposed >> > > > changes >> > > > > > > are voted on. >> > > > > > > 7. A vote to accept the document will close all discussion under >> > the >> > > > > > > process documented in this email >> > > > > > > 8. Once the document is accepted any subsequent changes will be >> > > > > > > performed as specified in the accepted process document. >> > > > > > > >> > > > > > > The purpose of this exercise is to arrive at a consensus for how >> > this >> > > > > > > project will operate within the guidelines and requirements of >> > the >> > > > > Apache >> > > > > > > organization. >> > > > > > > >> > > > > > > Thanks for participating, >> > > > > > > Claude >> > > > > > >> > > > > > >> > --------------------------------------------------------------------- >> > > > > > To unsubscribe, e-mail: [email protected] >> > > > > > For additional commands, e-mail: [email protected] >> > > > > > >> > > > > >> > > > >> > -- Alexandru Nedelcu alexn.org --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
