[PROPOSAL] use git branches for large or risky changes

[Myrle Krantz <my...@apache.org>]

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/

Re: [PROPOSAL] use git branches for large or risky changes

[Myrle Krantz <my...@apache.org>]

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 <ni...@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 <is...@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 <my...@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/
> > >
> >
>

Re: [PROPOSAL] use git branches for large or risky changes

[Nikhil Pawar <ni...@gmail.com>]

I agree, at least commiters should be allowed to do this.

Regards,
Nikhil

On Fri, Mar 15, 2019 at 3:19 PM Isaac Kamga <is...@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 <my...@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/
> >
>

Re: [PROPOSAL] use git branches for large or risky changes

[Isaac Kamga <is...@mifos.org>]

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 <my...@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/
>