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

[Niels de Vos]

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 :)

Niels