fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <Ross.Gard...@microsoft.com>
Subject RE: Single thread per topic please (was RE: [DISCUSS] Git procedure and branching model)
Date Mon, 04 Jan 2016 14:32:03 GMT
It's up to this community to decide on the best way forward, but I'll make one final point
re discussions using tools other than the mailing list.

Myrle states (and I agree): "it is important when new people join a project for them to be
able to follow why certain decisions were made the way they were"

This correct observation is why I am a big supporter of *all* discussion, and therefore the
background for *all* decisions, to be on *the* mailing list (dev@ being the one true list).
This way everyone knows where to find the background and where to participate. There's no
need to spend time learning the processes that say "decision type A is on confluence", "decision
type B is on JIRA", "decision type C is on ...." etc.

Myrle is also correct that conversation can become rambling, but it's not the medium that
makes that happen, it's people. We just have to do the best we can to stay on track and, in
my experience, it's easier to do that with a disciplined us of email and clear subject lines.

Either way, the most important thing is not to kill valuable contribution. If Myrle wants
to try things out on confluence then nobody should get in his way. Actions speak far louder
than words and if Myrle's actions encourage contributions then we will all be happy.

Ross 

-----Original Message-----
From: Myrle Krantz [mailto:mkrantz@mifos.org] 
Sent: Monday, January 4, 2016 2:20 PM
To: dev@fineract.incubator.apache.org
Subject: Re: Single thread per topic please (was RE: [DISCUSS] Git procedure and branching
model)

Hey Ross,

I think you're overestimating my contribution there.  All I did was scrape the thread and
put the stuff I thought should be captured into wiki pages.
I agree that we should stick to one topic per thread.  I was a little annoyed that the original
thread seemed to lack focus and that was why I did what I did.  You probably couldn't see
that content in the thread from where you were looking though.  It wasn't quoted in the email
that I responded to.  It was earlier in the thread, and working on getting lost.

The part of your mail that we likely actually disagree on is the use of confluence.

I think we've already demonstrated that conversations in a mailing thread tend to meander.
 That has it's place.  It's even necessary for creative work.  But when I'm looking for a
concrete result, I believe it helps when the object under consideration is right there where
the discussion occurs.
I like the fact that confluence improves the locality of these kinds of conversations.

I also believe that in some cases it is important when new people join a project for them
to be able to follow why certain decisions were made the way they were.  If the conversation
is attached to the decision documentation, it's much easier to find. And if no conversation
is attached, it's easy for new people to see that there wasn't much consideration put into
a given decision.  This also helps newbies avoid emotional mine fields.  (Have you ever joined
a project as a newcomer and asked about a specific decision only to have it blow up unexpectedly
in your face because people have discussed it long enough to be emotional about it?  I have...)

I suggest anyone who wants to stay up-to-date on the topic addressed on a certain wiki page
add themselves as a watcher to the page.  This has another advantage too: those who *aren't*
interested in a certain topic can avoid e-mails on that topic.  I know what it's like to be
overwhelmed by e-mails, and I like the way confluence helps me to manage that burden.  I try
to be respectful of others time, by scoping my communications respectfully.

I appreciate your input as mentor, but on this one, unless the community speaks up and asks
for something different of me, I will continue to use confluence for conversations in certain
cases (and JIRA in others).

I sure hope someone else from the community speaks up though, one way or the other.  Right
now, I'm really wondering where everyone is.

Greets from Germany,
Myrle Krantz


*Myrle Krantz*
Solutions Architect
RɅĐɅЯ, The Mifos Initiative
mkrantz@mifos.org | Skype: https://na01.safelinks.protection.outlook.com/?url=mkrantz.mifos.org&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cc429c0c598d54abd59a308d315122845%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1RvKkTh7ZBHtwZ%2bTgto2JBS3BpZ%2fOtAL8KGOFnLSveo%3d
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmifos.org&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cc429c0c598d54abd59a308d315122845%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=72m3lc3uM%2bOGI0c8QpRrZnaQmlZEtej2ZKN%2bUZyz7HU%3d
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffacebook.com%2fmifos&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cc429c0c598d54abd59a308d315122845%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DwqCldBEOqILBpr4WRmlqIr1blv6M35GQgbBZODomWk%3d>
 <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.twitter.com%2fmifos&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cc429c0c598d54abd59a308d315122845%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pj5Ln9EsxHOx0Uzmc8i6B3OVFCXdgueskeBhVtXr4eE%3d>


On Fri, Jan 1, 2016 at 5:25 PM, Ross Gardler <Ross.Gardler@microsoft.com>
wrote:

> For inclusiveness I recommend all discussion happens here in a new, 
> targeted, thread on dev.
>
> The mail below has 4 or 5 different topics covered and is posted to a 
> thread which is doesn't directly relate to any of those topics. 
> Furthermore it encourages further discussion in a different location. 
> This makes it difficult for people, as community members, to know 
> whether they want to skip, speed read or carefully review its content.
>
> Please ensure you use a single location for all communications to 
> avoid a splintering of the community.
>
> Ross
>
> ---Original Message-----
> From: Myrle Krantz [mailto:mkrantz@mifos.org]
> Sent: Wednesday, December 30, 2015 9:42 PM
> To: dev@fineract.incubator.apache.org
> Subject: Re: [DISCUSS] Git procedure and branching model
>
> Hi all, Hi Greg,
>
> With respect to adding committers, I've created a first draft proposal
> here:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki
> .apache.org%2fconfluence%2fdisplay%2fFINERACT%2fBecoming%2ba%2bCommitt
> er&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea0
> 8d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PzmS%2fmQSBln
> GTlJmIR%2bQ4GhDh%2bb2IBBsNnpLVLKIl80%3d
>
> All interested should feel free to discuss.  A new thread in @dev is 
> one way to conduct the discussion.  Another approach is to use the 
> commenting function in confluence.  Using the later, would keep the 
> discussion close to its content, and provide additional context for 
> anyone reading the document who wishes to understand how it evolved.
>
> After reading the release-stabilization section of the SVN release 
> process, I like many aspects of it.  It's clear that it has been built 
> out of a lot of experience.  But I still don't see any advantage to 
> using a STATUS file over using the JIRA ticket.  If I use JIRA tickets 
> with appropriately set release flags, and well-formulated searches, 
> they should cover the use
> cases that the STATUS file seems to address, and more.    Using the SVN
> process as a starting point, I've created a first draft proposal for 
> the FINERACT release process which replaces the STATUS file with JIRA 
> tickets
> here:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki
> .apache.org%2fconfluence%2fdisplay%2fFINERACT%2fStabilizing%2ba%2brele
> ase&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea
> 08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ien0%2btld6U
> OzQsa3a98Yoj0LaSfbrAB67z%2bECvr%2fsTE%3d
>
> I've also created a first draft proposal for release versioning, also 
> based on the SVN versioning, and on Markus' proposal.  You can find 
> the versioning proposal here:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki
> .apache.org%2fconfluence%2fdisplay%2fFINERACT%2fVersioning&data=01%7c0
> 1%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c
> 72f988bf86f141af91ab2d7cd011db47%7c1&sdata=svdPVCT8hpZEOC4AXN480oBqDiZ
> gzKSD90DwahIZlIE%3d
>
> I'm also considering adding confluence documents with more detailed 
> descriptions of what constitutes a critical bug, or a risky change.  
> If anyone has input on these topics (or would like to start a 
> document), please speak up.
>
> Please discuss and edit all three confluence documents.  They are not 
> mine.  They are ours.  Here they are listed again:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki
> .apache.org%2fconfluence%2fdisplay%2fFINERACT%2fBecoming%2ba%2bCommitt
> er&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea0
> 8d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PzmS%2fmQSBln
> GTlJmIR%2bQ4GhDh%2bb2IBBsNnpLVLKIl80%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki
> .apache.org%2fconfluence%2fdisplay%2fFINERACT%2fStabilizing%2ba%2brele
> ase&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea
> 08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ien0%2btld6U
> OzQsa3a98Yoj0LaSfbrAB67z%2bECvr%2fsTE%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki
> .apache.org%2fconfluence%2fdisplay%2fFINERACT%2fVersioning&data=01%7c0
> 1%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c
> 72f988bf86f141af91ab2d7cd011db47%7c1&sdata=svdPVCT8hpZEOC4AXN480oBqDiZ
> gzKSD90DwahIZlIE%3d
>
> Greetings from little Lüxheim, Germany Myrle
>
>
> *Myrle Krantz*
> Solutions Architect
> RɅĐɅЯ, The Mifos Initiative
> mkrantz@mifos.org | Skype:
> https://na01.safelinks.protection.outlook.com/?url=mkrantz.mifos.org&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nYBhfrXHGHzVvY9ZK74YXyeejRWkNgfdQaPeswMZe%2b0%3d
> |
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmifos.org&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NHgwnlwyYKGoiPoaILVnK3FIhgMVos2lzXsDsHEXRTw%3d
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffacebook.com%2fmifos&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7xF%2f24QFMOBcCx3h2WS%2f6%2bkyUy1AlFW4MxyzvsTrxRk%3d>
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.twitter.com%2fmifos&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mjrwFaanZPZbwpnwL5Ko6E4wwWkapVD7N2SBWy1PWC4%3d
> >
>
>
> On Tue, Dec 29, 2015 at 11:10 PM, Greg Stein <gstein@gmail.com> wrote:
>
> > On Tue, Dec 29, 2015 at 10:12 AM, Markus Geiss <markus.geiss@live.de>
> > wrote:
> >
> > > Looks like attachments won't work, so let me try to explain in
> > > words. ; o)
> > >
> > > We use the branch develop for ongoing new feature, enhancements, and
> > > bug fixe development. Aside from really small changes (like a typo),
> > > a developer/contributor creates a feature branch for his development
> > > effort. Once he is done with his work, he prepares and sends a Pull
> > > Request.
> > >
> >
> > Alright... I think here is the disconnect. I'd suggest just not
> > naming/labeling these people. Everybody is a "developer" and a
> > "contributor", so using those terms is ambiguous.
> >
> > From our standpoint, we just see Pull Requests from those without
> > commit rights.
> >
> > For those *with* commit rights, they are trusted to commit to the
> "develop"
> > branch at-will. They are *also* trusted to do large-ish or
> > questionable work on a branch first, and ask the community if they
> > agree with that work for merging. They are also trusted to do large
> > and approved feature work in an incremental fashion on the develop
> > branch, if that doesn't interfere with its stability.
> >
> > IMO, people will be watching the develop branch, and its continuous
> > integration / builds, and ignore all other branches. It is kind of
> > natural human behavior. Thus, to get the most eyes, reviews, and
> > testing: it should be done on the develop branch.
> >
> >
> > > A committer is doing a review of the changes, and if necessary,
> > > comments on the Pull Request suggestion some changes. Once the Pull
> > > Request is in line with our code conventions, the committer pulls
> > > this changes into the 'real' repo, is running a build to assure
> > > tests won't fail, and commits them. No need for any voting, he has
> > > earned the right to do so, and this is good.
> > >
> >
> > Yup.
> >
> > Let's hope the Pull Requests are minimal ... make those people
> > committers early and often :-) ... this *is* source control. They
> > can't really hurt anything, hmm? Fix it forward, or roll it back.
> >
> > ... this should be a new thread: how does this community want to add
> > new committers? It should be discussed "soon", so there is a known
> > process for when somebody arrives.
> >
> >
> > > If a release is to be made, the self-appointed Release Manager
> > > creates a new branch from develop, named after the release, and
> > > assures that all tests are running, all needed documentation is in
> > > place, and the ASF policies are fulfilled. During this period, the
> > > ongoing development can happen as described above, no need to stop
> > > others on working for the project. During this phase, it is feasible
> > > and sometimes needed to pull bug fixes, or additional features from
> > > the develop branch into the release, that's fine.
> >
> >
> > Agreed!
> >
> > Here is a sample of the STATUS file that I was talking about:
> >
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsvn.ap
> > ache.org%2frepos%2fasf%2fsubversion%2fbranches%2f1.9.x%2fSTATUS&data=0
> > 1%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621c
> > b3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=I9Qh3ziBSp5aDj9bSSxn6k
> > iPid1InwRnDsKE%2fblOi8c%3d
> >
> > That is a good process for cherry-picking changes into the release
> branch.
> > Ignore the first half-dozen paragraphs about timing and whatnot, but
> > this section gives a "how to" on a STATUS file:
> >
> >
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsubver
> > sion.apache.org%2fdocs%2fcommunity-guide%2freleasing.html%23release-st
> > abilization&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b4
> > 4ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=xj3g
> > zf%2feMJsNzBKxlb7H7oR5aWGJy6eVdPxwvuGRi6E%3d
> >
> > The Apache HTTP Server has a similar file:
> >
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsvn.ap
> > ache.org%2frepos%2fasf%2fhttpd%2fhttpd%2fbranches%2f2.4.x%2fSTATUS&dat
> > a=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d3116
> > 21cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=k6Z8Ujsq2o8QAdpXNln
> > R2I7UCcz5%2fGLceig2yQY2mqM%3d
> >
> > but it isn't as well-documented, thus my pointer to Subversion.
> >
> > >...
> >
> > Cheers,
> > -g
> >
>
Mime
View raw message