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

[Vijay Bellur]

On Tuesday 23 June 2015 10:35 AM, Dan Lambright wrote:
>
>
> ----- Original Message -----
>> From: "Vijay Bellur" <vbellur at redhat.com>
>> To: maintainers at gluster.org
>> Sent: Tuesday, June 23, 2015 9:43:11 AM
>> Subject: Re: [Gluster-Maintainers] Community Transparency [Was: Responsibilities and expectations of our maintainers]
>>
>> Hey All,
>>
>> I know that all of us are quite occupied at this point in time. I would
>> love to have some responses on this one. Will appreciate greatly if you
>> can spare some time off your schedule and chime in with your inputs.
>>
>> Thanks,
>> Vijay
>>
>> On Friday 19 June 2015 06:30 AM, Vijay Bellur wrote:
>>> Re-kindling the discussion again on this list.
>>>
>>> I agree with everything that Niels mentions here as expectations. In
>>> addition I would like us to start thinking about building more
>>> transparency in the community on how we operate as maintainers and also
>>> lead by example so that it is very evident to the broader community
>>> about we being serious about walking the talk.
>>>
>>> I would like us to think about a small list so that it can be
>>> accomplished sooner than later. My top 3 for this list would be:
>>>
>>> 1. Some of the goals for maintainers are measurable: reviews completed,
>>> reviews outstanding, attendance in IRC meetings, bugzilla backlog,
>>> patches sent etc. We can send a report at some frequency
>>> (bi-weekly/monthly) about these aspects so that the community observes
>>> the quantitative aspects of our involvement.
>
> Can some of these items be automated?
>

Yes, most of these can be automated. I already have scripts that pull 
data off gerrit. bugzilla can be easily automated too, for IRC meetings 
we have logs and hence pulling out statistics should not be difficult. 
If we agree on the set of quantifiable metrics that we'd like to see, I 
can work on making that happen.

>>>
>>> 2. Sending a report at some frequency (weekly/bi-weekly) about
>>> non-measurable aspects like happenings in our components, what we intend
>>> doing in the near to mid term etc. This could also be a good way to get
>>> more contributors to work on the immense backlog that all of us have and
>>> also help explain to the broader community about why we are doing
>>> something.
>
> A template describing the report contents would be useful. If a single person
> could take on the responsibility of reminding us to create these reports, and
> ensure they are sent and edited properly, that would also be good. This would
> be a "maintainer liaison" to the community.

That seems like a good idea, we can have this "maintainer liaison" role 
rotate too. In my mind, the minimal list of things that we want to 
include (since the last time the report was sent). would be:

1. Major patches that got merged with a small description of each

2. Update on ongoing development

3. Areas where we could do with community help (new development, bug 
fixes, bug triage etc.)

If we think more things are needed, I would be happy to spin up a 
template that we can fill in.

-Vijay

-Vijay