fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikhil Pawar <nickr...@gmail.com>
Subject Re: [PROPOSAL] use git branches for large or risky changes
Date Fri, 15 Mar 2019 19:33:01 GMT
I agree, at least commiters should be allowed to do this.

Regards,
Nikhil

On Fri, Mar 15, 2019 at 3:19 PM Isaac Kamga <isaac.kamga@mifos.org> wrote:

> 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