[Gluster-Maintainers] Community Transparency [Was: Responsibilities and expectations of our maintainers]

[Krishnan Parthasarathi]

----- Original Message -----
> On Mon, Jun 29, 2015 at 01:43:12AM -0400, Krishnan Parthasarathi wrote:
> > 
> > 
> > ----- Original Message -----
> > > On Wed, Jun 24, 2015 at 12:39:39AM -0400, Krishnan Parthasarathi wrote:
> > > > 
> > > > > Currently, we need more attention to the way of working, in and with,
> > > > > the community and see how to increase the outreach of all the work we
> > > > > are doing, else we may induce estrangement in this space.
> > > > > 
> > > > 
> > > > Yes. We could improve our engagement during design proposals.
> > > > Oftentimes,
> > > > there
> > > > is an announcement style mail and then the commit.
> > > 
> > > More often than not, I do not see an announcement style email. We only
> > > seem to do that for bigger changes, not smaller ones or things that are
> > > contained to only one component.
> > 
> > As long as we recognise that it has happened for big changes and is
> > unhealthy
> > is good. Lack of discussion for big changes makes maintaining them
> > difficult.
> > A streamlined merge-window based approach would help in scheduling big
> > changes,
> > giving time for more discussion. Thoughts?
> 
> I think a "merge window" mainly helps the top most maintainers, like
> Linus for the Linux kernel. He normally gets merge requests sent by
> sub-tree maintainers. Those sub-tree maintainers (who also have other
> sub-tree maintainers) often accept patches outside of the merge window
> too. There is a certain expectation of Linus merging all requests from
> other maintainers during the "merge window".
> 
> In the case for our maintainers, we do not get "ready to merge" patches.
> We still need to review them. A "review window" sounds more suitable for
> how we work, and it sets the right expectations for developers posting
> patches.
> 
> Consider something like this:
>  - a monthly schedule, starting the 1st of each month
>  - 3 weeks of "post anything"
>  - last week+ for "review window"
> 
> The problem I see with this, is that we 'allow' maintainers to not
> review changes in a timely matter. IMHO we should give feedback on
> patches as quickly as possible, keep the developers engaged in fixing
> and updating their change.
> 
> A "review window" (or several) for new features and big changes when we
> plan for a new release would be good. It should force developers to post
> their patches much in advance. If they did not post them before the
> "review window", those changes will not be considered for the release.
> 
> This would require us to categorize "new features" and "big changes". I
> think the "new features" should be obvious, and I see "big changes" as
> a patch(series) of 100+ lines of code modifications (sometimes smaller,
> more complex patches too).
> 
> Well, those are my 1st thoughts :)

Sounds OK to me.