I will reiterate the challenge is code quality & functionality must be aligned w broader needs.
We need less features, more quality, more test coverage, better performance, better security, contributions driven by actual market needs. As a compromise I’ve suggested that we accept the GSoC code contributions from the Mifos project but to put them in a separate branch. Otherwise we will need a lot more review and the GSOC volunteer can get frustrated that their PR keeps getting rejected (which has happened in the past). I think it’s good to have them on their branches and to have a lighter review of that. They can use that as the metric of success rather than having the PR accepted into the mainline. It’s not a requirement to have their functional idea make it upstream or shouldn’t be. On Sun, Apr 13, 2025 at 12:40 PM Adam Monsen <amon...@mifos.org> wrote: > Yep, agreed, +1 for keeping it simple and just using PRs > > On Sun, Apr 13, 2025 at 11:47 AM Aleksandar Vidakovic < > chee...@monkeysintown.com> wrote: > >> ... is this really necessary? The students are creating their own >> forks/PRs anyway... maybe I'm not entirely following, but working on their >> PRs seems to be sufficient to me... >> >> On Fri, Apr 11, 2025 at 9:26 PM Adam Monsen <amon...@mifos.org> wrote: >> >>> James wrote: >>> >>>> There isn’t a way to implement different branch level commit rights >>>> >>> >>> I think you *can* actually do that, but I wouldn't recommend it. It >>> appears to be a complex and proprietary/unique (e.g. non-portable) GitHub >>> feature. I haven't tried it before, I'm just getting this from >>> https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets >>> and what I see for my repo at >>> https://github.com/meonkeys/shb/settings/rules/new?target=branch >>> >>
