Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-07-20 Thread Amar Tumballi 
On Thu, Jun 29, 2017 at 10:58 AM, Amar Tumballi  wrote:

> All,
>
> Thanks for participating actively in the discussions. With all your
> co-operation we now have a update on maintainers 2.0 proposal. Vijay Bellur
> sent a patch last week [1] capturing all the discussions.
>
> Please go through the patch and see if you have any more concerns. There
> are many new names in there, so just review it so you can Ack it. Niels
> (ndevos) added all the people with their name on maintainers file as
> reviewers for the patch. Please take some time today and give +1 to it to
> acknowledge you are aware of the responsibilities. After 20 or more +1 on
> the patch, we will merge the patch, and accordingly raise a ticket to
> update the access to merge rights etc.
>
> Also, if your name is added in maintainers list (even as peer for
> component), please become member of Maintainers mailing list [2] This list
> is an open list (all archives available for anyone to read) so make sure
> you subscribe and become members.  Make sure you update your calendars with
> maintainer meeting timings, so you can attend it.
>
> [1] - https://review.gluster.org/17583
> [2] - http://lists.gluster.org/mailman/listinfo/maintainers
>
> Main maintainers 2.0 proposal link: https://hackmd.io/s/SkwiZd4qe
>
>
Thanks everyone. This activity is now complete. I have also raised a bug to
get the merge access to relevant maintainers on their components [3].

Every new maintainers, please make a note to become member of the mailing
list mentioned above this week, so you all can participate in the bi-weekly
maintainers' meeting.

Regards,
Amar

[3] - https://bugzilla.redhat.com/show_bug.cgi?id=1473525



> Write back if you have any more concerns.
>
> Regards,
> Amar
>
>
>
> On Tue, Apr 18, 2017 at 2:27 PM, Michael Scherer 
> wrote:
>
>> Le mardi 18 avril 2017 à 10:25 +0200, Niels de Vos a écrit :
>> > On Mon, Apr 17, 2017 at 04:53:55PM -0700, Amye Scavarda wrote:
>> > > On Fri, Apr 14, 2017 at 2:40 AM, Michael Scherer > >
>> > > wrote:
>> > >
>> > > > Le jeudi 13 avril 2017 à 18:01 -0700, Amye Scavarda a écrit :
>> > > > > In light of community conversations, I've put some revisions on
>> the
>> > > > > Maintainers changes, outlined in the hackmd pad:
>> > > > > https://hackmd.io/s/SkwiZd4qe
>> > > > >
>> > > > > Feedback welcomed!
>> > > > >
>> > > > > Note that the goals of this are to expand out our reach as a
>> project
>> > > > > (Gluster.org) and make it easy to define who's a maintainer for
>> what
>> > > > > feature.
>> > > > > I'll highlight the goals in the document here:
>> > > > >
>> > > > > * Refine how we declare component owners in Gluster
>> > > > > * Create a deeper sense of ownership throughout the open source
>> project
>> > > > > * Welcome more contibutors at a project impacting level
>> > > > >
>> > > > > We've clarified what the levels of 'owners' and 'peers' are in
>> terms of
>> > > > > responsibility, and we'll look to implement this in the 3.12
>> cycle.
>> > > > > Thanks!
>> > > >
>> > > > So, I realize that the concept of component is not defined in the
>> > > > document. I assume everybody have a shared understanding about what
>> it
>> > > > is, but maybe not, so wouldn't it make sense to define it more
>> clearly ?
>> > > >
>> > > > Is this planned to be done later as part of "We will be working on
>> > > > carving out new components for things that make logical sense." ?
>> > > >
>> > > > As for example, with regard to my previous comment, would
>> > > > "infrastructure" be a component, would "documentation" be a
>> component ?
>> > > >
>> > > > My understanding is that there's a working spreadsheet being
>> refined to
>> > > sort out what's an area that needs a maintainer defined, and what's
>> > > something that maybe doesn't need a named maintainer. Documentation
>> is a
>> > > tricky place to get to, because that's something that you do just
>> naturally
>> > > so that future-you doesn't hate current-you.
>> >
>> > I agree that documentation should be part of the standard development
>> > workflow. Unfortunately, this is not something that gets done without
>> > reminding everyone about it. We still need maintainers/owners to bug
>> > developers for documentation of new features, monitor the pull-request
>> > queue and decide if the documentation is written in an acceptible way.
>>
>> There is also the overall issue iof documentation consistency. For
>> example, style, glossary, etc, all kind of stuff that shouldn't be per
>> component but aligned overall.
>>
>> > The maintenance of the gluster.readthedocs.io site might be a
>> > infrastructure task?
>>
>> Wouldn't it be more logical to have it managed by the people that did
>> champion RTD ? I am unable to find the discussions about it, but I am
>> quite sure I had some concerns regarding RTD and wouldn't volunteer to
>> maintain something where I had objections (such as "being unable to fix
>>

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-04-18 Thread Michael Scherer 
Le mardi 18 avril 2017 à 10:25 +0200, Niels de Vos a écrit :
> On Mon, Apr 17, 2017 at 04:53:55PM -0700, Amye Scavarda wrote:
> > On Fri, Apr 14, 2017 at 2:40 AM, Michael Scherer 
> > wrote:
> > 
> > > Le jeudi 13 avril 2017 à 18:01 -0700, Amye Scavarda a écrit :
> > > > In light of community conversations, I've put some revisions on the
> > > > Maintainers changes, outlined in the hackmd pad:
> > > > https://hackmd.io/s/SkwiZd4qe
> > > >
> > > > Feedback welcomed!
> > > >
> > > > Note that the goals of this are to expand out our reach as a project
> > > > (Gluster.org) and make it easy to define who's a maintainer for what
> > > > feature.
> > > > I'll highlight the goals in the document here:
> > > >
> > > > * Refine how we declare component owners in Gluster
> > > > * Create a deeper sense of ownership throughout the open source project
> > > > * Welcome more contibutors at a project impacting level
> > > >
> > > > We've clarified what the levels of 'owners' and 'peers' are in terms of
> > > > responsibility, and we'll look to implement this in the 3.12 cycle.
> > > > Thanks!
> > >
> > > So, I realize that the concept of component is not defined in the
> > > document. I assume everybody have a shared understanding about what it
> > > is, but maybe not, so wouldn't it make sense to define it more clearly ?
> > >
> > > Is this planned to be done later as part of "We will be working on
> > > carving out new components for things that make logical sense." ?
> > >
> > > As for example, with regard to my previous comment, would
> > > "infrastructure" be a component, would "documentation" be a component ?
> > >
> > > My understanding is that there's a working spreadsheet being refined to
> > sort out what's an area that needs a maintainer defined, and what's
> > something that maybe doesn't need a named maintainer. Documentation is a
> > tricky place to get to, because that's something that you do just naturally
> > so that future-you doesn't hate current-you.
> 
> I agree that documentation should be part of the standard development
> workflow. Unfortunately, this is not something that gets done without
> reminding everyone about it. We still need maintainers/owners to bug
> developers for documentation of new features, monitor the pull-request
> queue and decide if the documentation is written in an acceptible way.

There is also the overall issue iof documentation consistency. For
example, style, glossary, etc, all kind of stuff that shouldn't be per
component but aligned overall.

> The maintenance of the gluster.readthedocs.io site might be a
> infrastructure task?

Wouldn't it be more logical to have it managed by the people that did
champion RTD ? I am unable to find the discussions about it, but I am
quite sure I had some concerns regarding RTD and wouldn't volunteer to
maintain something where I had objections (such as "being unable to fix
anything" is quite high on my usual objection list for taking
responsibility of a piece of infra)
-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS




signature.asc
Description: This is a digitally signed message part
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-04-18 Thread Niels de Vos 
On Mon, Apr 17, 2017 at 04:53:55PM -0700, Amye Scavarda wrote:
> On Fri, Apr 14, 2017 at 2:40 AM, Michael Scherer 
> wrote:
> 
> > Le jeudi 13 avril 2017 à 18:01 -0700, Amye Scavarda a écrit :
> > > In light of community conversations, I've put some revisions on the
> > > Maintainers changes, outlined in the hackmd pad:
> > > https://hackmd.io/s/SkwiZd4qe
> > >
> > > Feedback welcomed!
> > >
> > > Note that the goals of this are to expand out our reach as a project
> > > (Gluster.org) and make it easy to define who's a maintainer for what
> > > feature.
> > > I'll highlight the goals in the document here:
> > >
> > > * Refine how we declare component owners in Gluster
> > > * Create a deeper sense of ownership throughout the open source project
> > > * Welcome more contibutors at a project impacting level
> > >
> > > We've clarified what the levels of 'owners' and 'peers' are in terms of
> > > responsibility, and we'll look to implement this in the 3.12 cycle.
> > > Thanks!
> >
> > So, I realize that the concept of component is not defined in the
> > document. I assume everybody have a shared understanding about what it
> > is, but maybe not, so wouldn't it make sense to define it more clearly ?
> >
> > Is this planned to be done later as part of "We will be working on
> > carving out new components for things that make logical sense." ?
> >
> > As for example, with regard to my previous comment, would
> > "infrastructure" be a component, would "documentation" be a component ?
> >
> > My understanding is that there's a working spreadsheet being refined to
> sort out what's an area that needs a maintainer defined, and what's
> something that maybe doesn't need a named maintainer. Documentation is a
> tricky place to get to, because that's something that you do just naturally
> so that future-you doesn't hate current-you.

I agree that documentation should be part of the standard development
workflow. Unfortunately, this is not something that gets done without
reminding everyone about it. We still need maintainers/owners to bug
developers for documentation of new features, monitor the pull-request
queue and decide if the documentation is written in an acceptible way.
The maintenance of the gluster.readthedocs.io site might be a
infrastructure task?

At least for every component/task, we should have an 'owner' that can
be reached when someone has questions or problems are reported.

Thanks,
Niels


> However, I'll see if I can't find that spreadsheet because the above
> document is more guidelines than practical reality.
> Anything else?
>  - amye
> 
> 
> > --
> > Michael Scherer
> > Sysadmin, Community Infrastructure and Platform, OSAS
> >
> >
> >
> > ___
> > maintainers mailing list
> > maintain...@gluster.org
> > http://lists.gluster.org/mailman/listinfo/maintainers
> >
> >
> 
> 
> -- 
> Amye Scavarda | a...@redhat.com | Gluster Community Lead

> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers



signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-04-17 Thread Amye Scavarda 
Following up on this, this revision cycle is meant to be more clear about
owners + peers, and less focused on the Red Hat shorthand for levels of
responsibility.

As far as further goals, I think we can outline Architects and Leads
responsibility in a further cycle. I'll let Vijay respond to a further
governance document.
 -amye

On Fri, Apr 14, 2017 at 3:51 AM, Niels de Vos  wrote:

> On Fri, Apr 14, 2017 at 11:40:35AM +0200, Michael Scherer wrote:
> > Le jeudi 13 avril 2017 à 18:01 -0700, Amye Scavarda a écrit :
> > > In light of community conversations, I've put some revisions on the
> > > Maintainers changes, outlined in the hackmd pad:
> > > https://hackmd.io/s/SkwiZd4qe
> > >
> > > Feedback welcomed!
> > >
> > > Note that the goals of this are to expand out our reach as a project
> > > (Gluster.org) and make it easy to define who's a maintainer for what
> > > feature.
> > > I'll highlight the goals in the document here:
> > >
> > > * Refine how we declare component owners in Gluster
> > > * Create a deeper sense of ownership throughout the open source project
> > > * Welcome more contibutors at a project impacting level
> > >
> > > We've clarified what the levels of 'owners' and 'peers' are in terms of
> > > responsibility, and we'll look to implement this in the 3.12 cycle.
> > > Thanks!
> >
> > So, I realize that the concept of component is not defined in the
> > document. I assume everybody have a shared understanding about what it
> > is, but maybe not, so wouldn't it make sense to define it more clearly ?
> >
> > Is this planned to be done later as part of "We will be working on
> > carving out new components for things that make logical sense." ?
> >
> > As for example, with regard to my previous comment, would
> > "infrastructure" be a component, would "documentation" be a component ?
>
> Indeed, that is one of the things that I mentioned in a similar way on
> the previous version of the document. Because the document is aimed at
> the Gluster Community, it should address not only the main GlusterFS
> project, but also other "components maintained by the community". There
> are many different projects in the Gluster Community, of which the
> GlusterFS project is one, infrastructure, documentation and probably all
> repositories under https://github.com/gluster are others. Modules for
> Samba, NFS-Ganesha and other "external" projects probably do not count
> towards "Gluster proper" and are not included in the "Maintainers 2.0"
> approach (mentioning the excluded kinds of projects would be a good
> thing too).
>
> Also, the other relevant "roles" like "Project Lead", "Community Lead"
> and "Project Architect" need to be explained with their
> responsibilities. A paragraph of their description should probably be
> added to the MAINTAINERS [0] file when that gets updated too. A single
> naming for the roles would be best (no more "maintainers" anywhere?).
> Where would it be listed who has which role in the Gluster Community?
>
> When I click through the previous conversation, much of the feedback
> that was given on an earlier version [1] has not been included or
> addressed it seems. In one of the emails Vijay mentioned a "project
> governance document" is being written, and that should probably give
> more clarity when reading the Maintainers 2.0 proposal. A link to that
> document would be helpful.
>
> Thanks,
> Niels
>
>
> 0. https://github.com/gluster/glusterfs/blob/master/MAINTAINERS
> 1. http://lists.gluster.org/pipermail/maintainers/2017-March/002368.html
>



-- 
Amye Scavarda | a...@redhat.com | Gluster Community Lead
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-04-17 Thread Amye Scavarda 
On Fri, Apr 14, 2017 at 2:40 AM, Michael Scherer 
wrote:

> Le jeudi 13 avril 2017 à 18:01 -0700, Amye Scavarda a écrit :
> > In light of community conversations, I've put some revisions on the
> > Maintainers changes, outlined in the hackmd pad:
> > https://hackmd.io/s/SkwiZd4qe
> >
> > Feedback welcomed!
> >
> > Note that the goals of this are to expand out our reach as a project
> > (Gluster.org) and make it easy to define who's a maintainer for what
> > feature.
> > I'll highlight the goals in the document here:
> >
> > * Refine how we declare component owners in Gluster
> > * Create a deeper sense of ownership throughout the open source project
> > * Welcome more contibutors at a project impacting level
> >
> > We've clarified what the levels of 'owners' and 'peers' are in terms of
> > responsibility, and we'll look to implement this in the 3.12 cycle.
> > Thanks!
>
> So, I realize that the concept of component is not defined in the
> document. I assume everybody have a shared understanding about what it
> is, but maybe not, so wouldn't it make sense to define it more clearly ?
>
> Is this planned to be done later as part of "We will be working on
> carving out new components for things that make logical sense." ?
>
> As for example, with regard to my previous comment, would
> "infrastructure" be a component, would "documentation" be a component ?
>
> My understanding is that there's a working spreadsheet being refined to
sort out what's an area that needs a maintainer defined, and what's
something that maybe doesn't need a named maintainer. Documentation is a
tricky place to get to, because that's something that you do just naturally
so that future-you doesn't hate current-you.

However, I'll see if I can't find that spreadsheet because the above
document is more guidelines than practical reality.
Anything else?
 - amye


> --
> Michael Scherer
> Sysadmin, Community Infrastructure and Platform, OSAS
>
>
>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>
>


-- 
Amye Scavarda | a...@redhat.com | Gluster Community Lead
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-04-14 Thread Niels de Vos 
On Fri, Apr 14, 2017 at 11:40:35AM +0200, Michael Scherer wrote:
> Le jeudi 13 avril 2017 à 18:01 -0700, Amye Scavarda a écrit :
> > In light of community conversations, I've put some revisions on the
> > Maintainers changes, outlined in the hackmd pad:
> > https://hackmd.io/s/SkwiZd4qe
> > 
> > Feedback welcomed!
> > 
> > Note that the goals of this are to expand out our reach as a project
> > (Gluster.org) and make it easy to define who's a maintainer for what
> > feature.
> > I'll highlight the goals in the document here:
> > 
> > * Refine how we declare component owners in Gluster
> > * Create a deeper sense of ownership throughout the open source project
> > * Welcome more contibutors at a project impacting level
> > 
> > We've clarified what the levels of 'owners' and 'peers' are in terms of
> > responsibility, and we'll look to implement this in the 3.12 cycle.
> > Thanks!
> 
> So, I realize that the concept of component is not defined in the
> document. I assume everybody have a shared understanding about what it
> is, but maybe not, so wouldn't it make sense to define it more clearly ?
> 
> Is this planned to be done later as part of "We will be working on
> carving out new components for things that make logical sense." ?
> 
> As for example, with regard to my previous comment, would
> "infrastructure" be a component, would "documentation" be a component ?

Indeed, that is one of the things that I mentioned in a similar way on
the previous version of the document. Because the document is aimed at
the Gluster Community, it should address not only the main GlusterFS
project, but also other "components maintained by the community". There
are many different projects in the Gluster Community, of which the
GlusterFS project is one, infrastructure, documentation and probably all
repositories under https://github.com/gluster are others. Modules for
Samba, NFS-Ganesha and other "external" projects probably do not count
towards "Gluster proper" and are not included in the "Maintainers 2.0"
approach (mentioning the excluded kinds of projects would be a good
thing too).

Also, the other relevant "roles" like "Project Lead", "Community Lead"
and "Project Architect" need to be explained with their
responsibilities. A paragraph of their description should probably be
added to the MAINTAINERS [0] file when that gets updated too. A single
naming for the roles would be best (no more "maintainers" anywhere?).
Where would it be listed who has which role in the Gluster Community?

When I click through the previous conversation, much of the feedback
that was given on an earlier version [1] has not been included or
addressed it seems. In one of the emails Vijay mentioned a "project
governance document" is being written, and that should probably give
more clarity when reading the Maintainers 2.0 proposal. A link to that
document would be helpful.

Thanks,
Niels


0. https://github.com/gluster/glusterfs/blob/master/MAINTAINERS
1. http://lists.gluster.org/pipermail/maintainers/2017-March/002368.html


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-04-14 Thread Michael Scherer 
Le jeudi 13 avril 2017 à 18:01 -0700, Amye Scavarda a écrit :
> In light of community conversations, I've put some revisions on the
> Maintainers changes, outlined in the hackmd pad:
> https://hackmd.io/s/SkwiZd4qe
> 
> Feedback welcomed!
> 
> Note that the goals of this are to expand out our reach as a project
> (Gluster.org) and make it easy to define who's a maintainer for what
> feature.
> I'll highlight the goals in the document here:
> 
> * Refine how we declare component owners in Gluster
> * Create a deeper sense of ownership throughout the open source project
> * Welcome more contibutors at a project impacting level
> 
> We've clarified what the levels of 'owners' and 'peers' are in terms of
> responsibility, and we'll look to implement this in the 3.12 cycle.
> Thanks!

So, I realize that the concept of component is not defined in the
document. I assume everybody have a shared understanding about what it
is, but maybe not, so wouldn't it make sense to define it more clearly ?

Is this planned to be done later as part of "We will be working on
carving out new components for things that make logical sense." ?

As for example, with regard to my previous comment, would
"infrastructure" be a component, would "documentation" be a component ?

-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS




signature.asc
Description: This is a digitally signed message part
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-04-13 Thread Amye Scavarda 
In light of community conversations, I've put some revisions on the
Maintainers changes, outlined in the hackmd pad:
https://hackmd.io/s/SkwiZd4qe

Feedback welcomed!

Note that the goals of this are to expand out our reach as a project
(Gluster.org) and make it easy to define who's a maintainer for what
feature.
I'll highlight the goals in the document here:

* Refine how we declare component owners in Gluster
* Create a deeper sense of ownership throughout the open source project
* Welcome more contibutors at a project impacting level

We've clarified what the levels of 'owners' and 'peers' are in terms of
responsibility, and we'll look to implement this in the 3.12 cycle.
Thanks!
-- amye


On Sat, Mar 25, 2017 at 2:50 PM, Vijay Bellur  wrote:

>
>
> On Sat, Mar 25, 2017 at 8:01 AM, Raghavendra Gowdappa  > wrote:
>
>>
>>
>> - Original Message -
>> > From: "Raghavendra Gowdappa" 
>> > To: "Pranith Kumar Karampuri" 
>> > Cc: "Amar Tumballi" , "GlusterFS Maintainers" <
>> maintain...@gluster.org>, "Gluster Devel"
>> > , "Michael Scherer" 
>> > Sent: Saturday, March 25, 2017 5:22:44 PM
>> > Subject: Re: [Gluster-Maintainers] [Gluster-devel] Maintainers 2.0
>> Proposal
>> >
>> >
>> >
>> > - Original Message -
>> > > From: "Pranith Kumar Karampuri" 
>> > > To: "Michael Scherer" 
>> > > Cc: "Amar Tumballi" , "GlusterFS Maintainers"
>> > > , "Gluster Devel"
>> > > 
>> > > Sent: Friday, March 24, 2017 7:12:32 PM
>> > > Subject: Re: [Gluster-Maintainers] [Gluster-devel] Maintainers 2.0
>> Proposal
>> > >
>> > > Do we also plan to publish similar guidelines for deciding on Project
>> > > maintainer?
>> >
>> > +1 for defining roles, responsibilities and qualifications of a Project
>> > manager.
>>
>> s/manager/maintainer/ :)
>>
>
>
> Agreed. There is a need to define the responsibilities of various roles -
> architects, project maintainers,  project and community leads. We have used
> some of these terms interchangeably in the past. Will add more details on
> these roles and provide more clarity.
>
>
>
>> >
>> > >
>> > > On Fri, Mar 24, 2017 at 2:24 AM, Michael Scherer <
>> msche...@redhat.com >
>> > > wrote:
>> > >
>> > >
>> > > Le samedi 18 mars 2017 à 16:47 +0530, Pranith Kumar Karampuri a écrit
>> :
>> > > > On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi <
>> atumb...@redhat.com >
>> > > > wrote:
>> > > >
>> > > > > I don't want to take the discussions in another direction, but
>> want
>> > > > > clarity on few things:
>> > > > >
>> > > > > 1. Does maintainers means they are only reviewing/ merging
>> patches?
>> > > > > 2. Should maintainers be responsible for answering ML / IRC
>> questions
>> > > > > (well, they should focus more on documentation IMO).
>> > > > > 3. Who's responsibility is it to keep the gluster.org webpage? I
>> > > > > personally feel the responsibility should be well defined.
>> > >
>> > > Theses point seems to have been overlooked (as no one answered), yet I
>> > > think they do matter if we want to expand the community besides
>> coders.
>> > >
>> > > And since one of the goal is to "Welcome more contibutors(sic) at a
>> > > project impacting level", I think we should be also speaking of
>> > > contributions besides code (ie, website, for example, documentation
>> for
>> > > another).
>> > >
>> > > While on it, I would like to see some points about:
>> > >
>> > > - ensure that someone is responsible for having the design discussion
>> in
>> > > the open
>> > > - ensure that each feature get proper testing when committed, and the
>> > > maintainers is responsible for making sure this happen
>> > > - ensure that each feature get documented when committed.
>> > >
>> > > If we think of contribution as a pipeline (kinda like the sales
>> funnel),
>> > > making sure there is documentation also mean people can use the
>> > > software, thus increasing the community, and so helping to recruit
>> > > people in a contributor pipeline.
>> > >
>> > > Proper testing means that it make refactoring easier, thus easing
>> > > contributions (ie, people can submit patches and see nothing break,
>> even
>> > > for new features), thus also making people likely more at ease to
>> submit
>> > > patches later.
>> > >
>> > > And making sure the design discussion occurs in the open is also more
>> > > welcoming to contributors, since they can see how we discuss, and
>> learn
>> > > from it.
>>
>
>
> Agree to all of these. The current guidelines for maintainers / owners
> lists most of these points as core responsibilities [1].
>
> Thanks,
> Vijay
>
>  [1] https://gluster.readthedocs.io/en/latest/
> Contributors-Guide/Guidelines-For-Maintainers/
>
> ___
> maintainers mailing list
>

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-03-25 Thread Vijay Bellur 
On Sat, Mar 25, 2017 at 8:01 AM, Raghavendra Gowdappa 
wrote:

>
>
> - Original Message -
> > From: "Raghavendra Gowdappa" 
> > To: "Pranith Kumar Karampuri" 
> > Cc: "Amar Tumballi" , "GlusterFS Maintainers" <
> maintain...@gluster.org>, "Gluster Devel"
> > , "Michael Scherer" 
> > Sent: Saturday, March 25, 2017 5:22:44 PM
> > Subject: Re: [Gluster-Maintainers] [Gluster-devel] Maintainers 2.0
> Proposal
> >
> >
> >
> > - Original Message -
> > > From: "Pranith Kumar Karampuri" 
> > > To: "Michael Scherer" 
> > > Cc: "Amar Tumballi" , "GlusterFS Maintainers"
> > > , "Gluster Devel"
> > > 
> > > Sent: Friday, March 24, 2017 7:12:32 PM
> > > Subject: Re: [Gluster-Maintainers] [Gluster-devel] Maintainers 2.0
> Proposal
> > >
> > > Do we also plan to publish similar guidelines for deciding on Project
> > > maintainer?
> >
> > +1 for defining roles, responsibilities and qualifications of a Project
> > manager.
>
> s/manager/maintainer/ :)
>


Agreed. There is a need to define the responsibilities of various roles -
architects, project maintainers,  project and community leads. We have used
some of these terms interchangeably in the past. Will add more details on
these roles and provide more clarity.



> >
> > >
> > > On Fri, Mar 24, 2017 at 2:24 AM, Michael Scherer < msche...@redhat.com
> >
> > > wrote:
> > >
> > >
> > > Le samedi 18 mars 2017 à 16:47 +0530, Pranith Kumar Karampuri a écrit :
> > > > On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi < atumb...@redhat.com
> >
> > > > wrote:
> > > >
> > > > > I don't want to take the discussions in another direction, but want
> > > > > clarity on few things:
> > > > >
> > > > > 1. Does maintainers means they are only reviewing/ merging patches?
> > > > > 2. Should maintainers be responsible for answering ML / IRC
> questions
> > > > > (well, they should focus more on documentation IMO).
> > > > > 3. Who's responsibility is it to keep the gluster.org webpage? I
> > > > > personally feel the responsibility should be well defined.
> > >
> > > Theses point seems to have been overlooked (as no one answered), yet I
> > > think they do matter if we want to expand the community besides coders.
> > >
> > > And since one of the goal is to "Welcome more contibutors(sic) at a
> > > project impacting level", I think we should be also speaking of
> > > contributions besides code (ie, website, for example, documentation for
> > > another).
> > >
> > > While on it, I would like to see some points about:
> > >
> > > - ensure that someone is responsible for having the design discussion
> in
> > > the open
> > > - ensure that each feature get proper testing when committed, and the
> > > maintainers is responsible for making sure this happen
> > > - ensure that each feature get documented when committed.
> > >
> > > If we think of contribution as a pipeline (kinda like the sales
> funnel),
> > > making sure there is documentation also mean people can use the
> > > software, thus increasing the community, and so helping to recruit
> > > people in a contributor pipeline.
> > >
> > > Proper testing means that it make refactoring easier, thus easing
> > > contributions (ie, people can submit patches and see nothing break,
> even
> > > for new features), thus also making people likely more at ease to
> submit
> > > patches later.
> > >
> > > And making sure the design discussion occurs in the open is also more
> > > welcoming to contributors, since they can see how we discuss, and learn
> > > from it.
>


Agree to all of these. The current guidelines for maintainers / owners
lists most of these points as core responsibilities [1].

Thanks,
Vijay

 [1]
https://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-03-25 Thread Raghavendra Gowdappa 


- Original Message -
> From: "Pranith Kumar Karampuri" 
> To: "Michael Scherer" 
> Cc: "Amar Tumballi" , "GlusterFS Maintainers" 
> , "Gluster Devel"
> 
> Sent: Friday, March 24, 2017 7:12:32 PM
> Subject: Re: [Gluster-Maintainers] [Gluster-devel] Maintainers 2.0 Proposal
> 
> Do we also plan to publish similar guidelines for deciding on Project
> maintainer?

+1 for defining roles, responsibilities and qualifications of a Project manager.

> 
> On Fri, Mar 24, 2017 at 2:24 AM, Michael Scherer < msche...@redhat.com >
> wrote:
> 
> 
> Le samedi 18 mars 2017 à 16:47 +0530, Pranith Kumar Karampuri a écrit :
> > On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi < atumb...@redhat.com >
> > wrote:
> > 
> > > I don't want to take the discussions in another direction, but want
> > > clarity on few things:
> > > 
> > > 1. Does maintainers means they are only reviewing/ merging patches?
> > > 2. Should maintainers be responsible for answering ML / IRC questions
> > > (well, they should focus more on documentation IMO).
> > > 3. Who's responsibility is it to keep the gluster.org webpage? I
> > > personally feel the responsibility should be well defined.
> 
> Theses point seems to have been overlooked (as no one answered), yet I
> think they do matter if we want to expand the community besides coders.
> 
> And since one of the goal is to "Welcome more contibutors(sic) at a
> project impacting level", I think we should be also speaking of
> contributions besides code (ie, website, for example, documentation for
> another).
> 
> While on it, I would like to see some points about:
> 
> - ensure that someone is responsible for having the design discussion in
> the open
> - ensure that each feature get proper testing when committed, and the
> maintainers is responsible for making sure this happen
> - ensure that each feature get documented when committed.
> 
> If we think of contribution as a pipeline (kinda like the sales funnel),
> making sure there is documentation also mean people can use the
> software, thus increasing the community, and so helping to recruit
> people in a contributor pipeline.
> 
> Proper testing means that it make refactoring easier, thus easing
> contributions (ie, people can submit patches and see nothing break, even
> for new features), thus also making people likely more at ease to submit
> patches later.
> 
> And making sure the design discussion occurs in the open is also more
> welcoming to contributors, since they can see how we discuss, and learn
> from it.
> 
> And while on it, is there a similar document being prepared about
> Community Lead and Project Lead (especially for transition, etc) ?
> --
> Michael Scherer
> Sysadmin, Community Infrastructure and Platform, OSAS
> 
> 
> 
> 
> 
> --
> Pranith
> 
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-03-18 Thread Vijay Bellur 
On Sat, Mar 18, 2017 at 7:27 AM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Thu, Mar 16, 2017 at 7:42 AM, Vijay Bellur  wrote:
>
>> Hi All,
>>
>> We have been working on a proposal [1] to make the lifecycle management
>> of Gluster maintainers more structured. We intend to make the proposal
>> effective around 3.11 (May 2016).
>>
>> Please review the proposal and let us know your feedback. If you need
>> clarity on any existing aspect or feel the need for something additional in
>> the proposal, please feel free to let us know.
>>
>
>
>-
>
>It’s okay to drop a component if they are not able to find
>time/energy. Owners are requested to minimize disruption to the project by
>helping with transitions and announcing their intentions.
>
> How and to who should it be communicated that a owner/peer is doing a bad
> job and there are better alternatives for the component?
>
>
All feedback should be directed to the project and community leaders. At
this point in time, please direct any feedback (both positive and negative)
to Amye, Jeff and me.

Thanks,
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Maintainers 2.0 Proposal

2017-03-18 Thread Vijay Bellur 
On Sat, Mar 18, 2017 at 7:17 AM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi 
> wrote:
>
>> I don't want to take the discussions in another direction, but want
>> clarity on few things:
>>
>> 1. Does maintainers means they are only reviewing/ merging patches?
>> 2. Should maintainers be responsible for answering ML / IRC questions
>> (well, they should focus more on documentation IMO).
>> 3. Who's responsibility is it to keep the gluster.org webpage? I
>> personally feel the responsibility should be well defined.
>> 4. Can a component have more than 1 owner ? 1 maintainers etc?
>>
>
> More than 1 maintainer is the best case we should aim for. I see EC
> benefit tremendously because of this. Work keeps moving because at least
> one of Xavi/I are available for discussions.
>


The number of maintainers will largely be a function of the complexity of
the component and the nature of ongoing work (features being designed,
patches for review, outstanding technical debt). The intent of this
exercise is not to disturb status quo for components where we do not have
problems.

Some of these questions should be clearly answered in document IMO.
>>
>
+1. We are evolving a project governance document and let us strive to
evolve as much clarity needed before making it effective.

Thanks,
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel