Hi all, let me leave some input as an Incubator mentor.
If this is the way you have been working so-far, I encourage to keep the rules that way. However, I would strongly encourage you not to put too many rules up front. I know the team around KIE is already an established project, however have I seen many projects kill the buzz in the community by putting up too many rules. The ones you mentioned make total sense … just wanted to leave this thread of thought here if you were thinking about putting up more new rules. Rules should fix problems a project is having and not try to prevent all sorts of problems from happening up-front. Everything is under version control, we can always revert a bad commit. Chris Von: Jason Porter <[email protected]> Datum: Mittwoch, 13. September 2023 um 21:57 An: [email protected] <[email protected]> Betreff: Re: [PROPOSAL] Policy for code changes This looks good, Alex. I’m happy with it. As you have mentioned in gchat, we can enforce some of these things by using the `.asf.yaml` file for GitHub[1]. I think that would be an excellent step to take to ensure we maintain the correct process. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features -- Jason Porter Software Engineer He/Him/His IBM From: Alex Porcelli <[email protected]> Date: Wednesday, September 13, 2023 at 11:26 To: [email protected] <[email protected]> Subject: [EXTERNAL] [PROPOSAL] Policy for code changes As we finally transition the codebase to the Apache Foundation [1], I think it's also essential to establish some process over code changes; based on that, here is a proposal: 1. No Direct Commits: Direct commits to our repositories are discouraged to maintain consistency and enhance collaborative efforts. All changes should be introduced via pull requests (PR) to ensure comprehensive review and community discussion before any code integration. 2. PR Merging Requirements: • Reviews: Each pull request should be reviewed and approved by at least two individuals: • One approval must come from a committer. • The other is from a PPMC member. • Checks: Before merging, all associated automated checks (e.g., CI builds, tests) with the PR must pass. 3. Addressing Flaky Tests or Unstable CI: If faced with flaky tests or an unstable CI environment: • An issue should be promptly documented. • The decision to merge or await further evaluation should be discussed and shared on the dev mailing list, ensuring transparency and community-wide input. By adopting these guidelines, we aim to fortify our commitment to code quality, transparency, and shared responsibility, all while accommodating our sizable community of committers. The above proposal has already been briefly discussed among the PPMC members. Feedback is more than welcome! [1] - https://lists.apache.org/thread/p2cq22chlcc64rxmdkc07ksvtzfk5trc Regards, Alex Porcelli PPMC for Apache KIE Podling --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
