fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrle Krantz <my...@apache.org>
Subject Re: [PROPOSAL] use git branches for large or risky changes
Date Sun, 17 Mar 2019 11:07:38 GMT
Excellent.  I'm going to call that a consensus.  On that basis, I've
created a branch for FINERACT-614, pulled in angelboxes changes and closed
this PR: https://github.com/apache/fineract/pull/465

Best Regards,
Myrle

On Fri, Mar 15, 2019 at 8:33 PM Nikhil Pawar <nickrp89@gmail.com> wrote:

> 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