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

[Shyam]

On 06/24/2015 01:06 AM, Venky Shankar wrote:
>
>
> On 06/24/2015 10:09 AM, 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.
>
> ..and more hangouts? Something like ceph developer summit (over
> hagnouts) would be good to have.
>
>>
>> We should improve the way we target features for a release. We must
>> adopt a
>> merge-window style of development (e.g linux-kernel). Jeff had some
>> thoughts around
>> this. Time shouldn't be an excuse for hurrying up features into a
>> release.
>
> Exactly. Something that's going on _now_ with the logging patches.

Good, let me make a few more statements about this example (considering 
I put in *this* feature a *long* while back).
   - Agree with Venky, that there is no call out in devel *now* to get 
this done, and so there is a gap in understanding targets (for me as well)
   - When this feature was put out and mails sent to devel there was 
little to no traction (which is fine), but there was also little to no 
comments on why this is good or bad, this does not help feature 
development (esp. infra changes)

What I want to state is that, if there are changes that can impact other 
components, we need better maintainer representation on comments and in 
general bettering the solution, so that we get in all the requirements 
straight and also deliver something that mostly does not need rework 
later and solves the need well enough. We also need adoption plans in 
other components, for such changes that cross component boundaries.

How can we better address this? (or are comments/suggestions already 
addressing the same?)

P.S: I think we are starting to demonstrate sufficient interest in this 
problem :) and that gives *me* great hope for the future...

NOTE: I am fine discussing specific features to enable problem 
understanding/resolution better, than consider it mud slinging, just 
saying...

>
>> More importantly, maintainers must be empowered to say _no_, when
>> design/code
>> submissions don't adhere to set expectations. Thoughts?
>> _______________________________________________
>> maintainers mailing list
>> maintainers at gluster.org
>> http://www.gluster.org/mailman/listinfo/maintainers
>
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers