Gluster users - Jul 2013 - [FEEDBACK] Governance of GlusterFS project

Hello everyone,

  We are in the process of formalizing the governance model of the
GlusterFS project. Historically, the governance of the project has been
loosely structured. This is an invitation to all of you to participate in
this discussion and provide your feedback and suggestions on how we should
evolve a formal model. Feedback from this thread will be considered to the
extent possible in formulating the draft (which will be sent out for review
as well).

  Here are some specific topics to seed the discussion:

- Core team formation
  - what are the qualifications for membership (e.g contributions of code,
doc, packaging, support on irc/lists, how to quantify?)
  - what are the responsibilities of the group (e.g direction of the
project, project roadmap, infrastructure, membership)

- Roadmap
  - process of proposing features
  - process of selection of features for release

- Release management
  - timelines and frequency
  - release themes
  - life cycle and support for releases
  - project management and tracking

- Project maintainers
  - qualification for membership
  - process and evaluation

There are a lot more topics which need to be discussed, I just named some
to get started. I am sure our community has members who belong and
participate (or at least are familiar with) other open source project
communities. Your feedback will be valuable.

Looking forward to hearing from you!

Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130726/7a28a263/attachment.html>

I would really like to see releases happen regularly and more
aggressively. So maybe this plan needs a community QA guy or the
release manager needs to take up that responsibility to say "this code
is good for including in the next version". (Maybe this falls under
process and evaluation?)

For example, I think the ext4 patches had long been available but they
just took forever to get pushed out into an official release.

I'm in favor of closing some bugs and risking introducing new bugs for
the sake of releases happening often.



On Fri, Jul 26, 2013 at 10:26 AM, Anand Avati <anand.avati at gmail.com>
wrote:
> Hello everyone,
>
>   We are in the process of formalizing the governance model of the
GlusterFS
> project. Historically, the governance of the project has been loosely
> structured. This is an invitation to all of you to participate in this
> discussion and provide your feedback and suggestions on how we should
evolve
> a formal model. Feedback from this thread will be considered to the extent
> possible in formulating the draft (which will be sent out for review as
> well).
>
>   Here are some specific topics to seed the discussion:
>
> - Core team formation
>   - what are the qualifications for membership (e.g contributions of code,
> doc, packaging, support on irc/lists, how to quantify?)
>   - what are the responsibilities of the group (e.g direction of the
> project, project roadmap, infrastructure, membership)
>
> - Roadmap
>   - process of proposing features
>   - process of selection of features for release
>
> - Release management
>   - timelines and frequency
>   - release themes
>   - life cycle and support for releases
>   - project management and tracking
>
> - Project maintainers
>   - qualification for membership
>   - process and evaluation
>
> There are a lot more topics which need to be discussed, I just named some
to
> get started. I am sure our community has members who belong and participate
> (or at least are familiar with) other open source project communities. Your
> feedback will be valuable.
>
> Looking forward to hearing from you!
>
> Avati
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users

Avati,

Glad that such a discussion came up :-)

Few comments inline.

>
>   Here are some specific topics to seed the discussion:
>
> - Core team formation
>   - what are the qualifications for membership (e.g contributions of code,
> doc, packaging, support on irc/lists, how to quantify?)
>   - what are the responsibilities of the group (e.g direction of the
> project, project roadmap, infrastructure, membership)
>
 - Core team structure/membership/goal is most important of all, as most
probably the responsibility of the group will be having a bearing on all
the below bullet points.
 - One thing to consider is, do we have any limit on number of people @
core team ?
    -> If not, then we have a long term problem of once people get in, they
may loose focus, interest etc (mgmt issues)
    -> If yes, what is the number, and then how long is the membership
valid ? (6months? 1yr? 2yr?)

> - Roadmap
>   - process of proposing features
>   - process of selection of features for release
>
>
Good to start with some guidelines from other projects.

> - Release management
>   - timelines and frequency
>   - release themes
>   - life cycle and support for releases
>   - project management and tracking
>
Same here, would be good to follow other project to start with, and then
corrections as we see it.

>
> - Project maintainers
>   - qualification for membership
>   - process and evaluation
>
>
Again, same questions like core team membership applies here.
Considering we are talking about whole project maintainership here, one
criteria should be the depth of understanding about framework.
- In considering contributions, just the number of contribution (ie, patch
count etc) alone should not be the goal here, but the impact of the changes
on the project also should be a metric.

Regards,
Amar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130727/eeac88f8/attachment.html>

Anand Avati <anand.avati at gmail.com> wrote:
>   We are in the process of formalizing the governance model of the
> GlusterFS project. Historically, the governance of the project has been
> loosely structured. This is an invitation to all of you to participate in
> this discussion and provide your feedback and suggestions on how we should
> evolve a formal model. 
IMO GlusterFS needs a governance that fits core developpers' tastes.
After all we speak about making decisions impacting the way they work.

As a minor contributor, I do not feel legitimate to push in any
direction. I can just share my experience in governance in projets I
know about (NetBSD, milter-greylist), if someone is interested. 

I can also point what looks like governance failure to me. It is a bit
annoying to have a show-stopper bug and see release cycle going from qa
to alpha to beta to release just like a river flows to the sea. Other
already said it, but there need to be some process to settle (bug,
feature) vs (release schedule) conflicts. It can be a single release
engineer, a release engineering team as a round table, or a democratic
vote from whatever group is prefered, but at least there should be some
accounted decision here. 

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu at netbsd.org

On Fri, Jul 26, 2013 at 10:56 PM, Anand Avati <anand.avati at gmail.com>
wrote:
>
> Looking forward to hearing from you!
Hi Avati,

As many said on the thread, frequent releases will be good.

Another aspect which we felt could be improved is the timely review
for the patches. Though this is the responsibility of the community as
the whole, I wonder if having component owners identified could help,
so that they could take interest in helping the patch reviews for
their components.

Regards,
Bharata.

One of the other things we missed in this thread is how to handle bugs in
bugzilla, and who should own the triage for high/urgent priority bugs.

-Amar


On Fri, Jul 26, 2013 at 10:56 PM, Anand Avati <anand.avati at gmail.com>
wrote:
> Hello everyone,
>
>   We are in the process of formalizing the governance model of the
> GlusterFS project. Historically, the governance of the project has been
> loosely structured. This is an invitation to all of you to participate in
> this discussion and provide your feedback and suggestions on how we should
> evolve a formal model. Feedback from this thread will be considered to the
> extent possible in formulating the draft (which will be sent out for review
> as well).
>
>   Here are some specific topics to seed the discussion:
>
> - Core team formation
>   - what are the qualifications for membership (e.g contributions of code,
> doc, packaging, support on irc/lists, how to quantify?)
>   - what are the responsibilities of the group (e.g direction of the
> project, project roadmap, infrastructure, membership)
>
> - Roadmap
>   - process of proposing features
>   - process of selection of features for release
>
> - Release management
>   - timelines and frequency
>   - release themes
>   - life cycle and support for releases
>   - project management and tracking
>
> - Project maintainers
>   - qualification for membership
>   - process and evaluation
>
> There are a lot more topics which need to be discussed, I just named some
> to get started. I am sure our community has members who belong and
> participate (or at least are familiar with) other open source project
> communities. Your feedback will be valuable.
>
> Looking forward to hearing from you!
>
> Avati
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130906/2d42b322/attachment.html>