On Sun, Apr 13, 2025 at 5:34 PM James Dailey <jamespdai...@gmail.com> wrote:
> 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. > +1. That all makes perfect sense. 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. > I agree if you s/branch/branches/. See Ádám and Kristof's emails... one branch per "feature" (coherent set of changes) is the right way to organize them. Each branch is then evaluated separately, the same way PRs are currently evaluated. "develop" is effectively "main" / "master" for this project. Take a minute to visualize what happens if work from 5 students is merged onto a branch that isn't develop... you've effectively created a fork with its own morass of interdependent code. I'd say just ditch the branch/branches idea. These *are* just PRs. If a PR isn't good enough to be merged into develop, that's as valuable a lesson as any. We've all been students and we know we need honest, accurate feedback/mentorship, even if it is frustrating. Just make a clear set of instructions/expectations for gsoc students up front. Warn them that it's hard to get their work upstream, and give gsoc students the opportunity to surprise us with excellent work. I think it’s good to have them on their branches and to have a lighter > review of that. > I disagree. Stick to the same standards we use for every other PR. "Review," even if it is "lighter," is still work for a mentor. That said, it might make sense to cut multiple PRs for one student's gsoc engagement. Each PR should be a reasonably-sized coherent chunk of work corresponding to a gsoc project milestone from the set of milestones negotiated between mentor and student prior to starting work. Or just cut a PR at a natural stopping point mid-gsoc, then start another. It’s not a requirement to have their functional idea make it upstream or > shouldn’t be. > I agree. There are many opportunities to evaluate a gsoc engagement; surely we could (or already have) come up with a holistic rubric, and it seems fine to leave out "code merged into develop". Some ideas: starts by writing failing tests, follows coding standards, suggests improvements and speaks up when something doesn't make sense, communicates well, explains intent well, asks for help, iteratively improves their work, shows up on time and prepared for meetings and/or communicates absences well when they cannot attend... etc.
