Thank you for the feedback, Chris. We're trying to strike a balance between moving to a new home and disrupting as little as possible the well established projects.
On Thu, Sep 14, 2023 at 4:31 AM Christofer Dutz <[email protected]> wrote: > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
