fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Isaac Kamga <isaac.ka...@mifos.org>
Subject Re: [PROPOSAL] use git branches for large or risky changes
Date Fri, 15 Mar 2019 19:19:27 GMT
Hello Myrle,

I support this proposal especially as it encourages developers to bring in
their changes earlier than later.

The community would also have to ensure that work doesn't suffer from
negligence too. Is there already the motivation to do that ? Asking because
sometimes even PRs on develop which are ready take months to get merged.

Cheers,
Isaac Kamga.

On Wed, Mar 13, 2019 at 11:57 AM Myrle Krantz <myrle@apache.org> wrote:

> Hey all,
>
> PROPOSAL:
> "Rather than ask contributors to squash everything into a single commit and
> our committers to merge it all at once, we should suggest the use of git
> branches for development which occurs over longer periods or larger line or
> file counts.  The branch should be named after the Jira ticket it
> corresponds to."
>
> This would have the following advantages:
> * make it possible for other contributors to collaborate on larger changes
> that aren't yet ready for primetime.  By choosing a finer granularity of
> collaboration, we would enable smaller contributions, and better engage our
> more casual volunteers.
> * bring the development process to Apache infrastructure earlier, which
> would provide more complete data for proposals to make a contributor into a
> committer.
> * provide more satisfaction to contributors: they get affirmation on each
> step of their process rather than getting that affirmation only once at the
> end. [1]  Psychology research shows this is a more motivating and kind way
> of giving feedback.
> * make it easier for me, personally to follow the development process
> retroactively.
>
> If y'all don't object to my proposal in the next 72 hours then I'm going to
> start applying it.
>
> Best Regards,
> Myrle
>
> 1.)
> https://upraise.io/blog/frequency-key-successful-performance-management/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message