Open Stack

On 22/04/15 05:57 +0000, Nikhil Komawar wrote:
>Hello all,
>
>With all due respect to all the Glance core-reviewers (who are doing an excellent job, by the way), please NO. First reaction that came to my mind after reading the title: What might be the thinking behind this, what is the direction this is driving the project towards, what’s next, open Glance core reviewers to all committers? I think not.

open core reviewers to committers? really?

>
>The prime reason:-
>===============
>Glance “drivers” is a role and very much like any other role, it revolves around responsibilities. The authority aspect of this role is a side-effect and a privilege given to help perform these responsibilities effectively. Similarly, Glance "core-reviewers" more commonly called as Glance cores is another responsibility. It revolves around managing the code that is proposed to be merged to the project code bases. So, how can something that’s approved by the drivers and not approved by the core reviewers get into the project? Although, the role played and the authority imposed may be different by both these groups, however that effect is observed by the community on the code proposed.
>
>The specs are open to the community and have set expectations for providing the details around subtle aspects like Deployer Impact, Security Impact, Developer Impact, etc. So, all of these groups can point out to the author if the respective expectations aren’t met. And the timely provided feedback will have to be weighed in by the drivers. As the name of the role suggests, these people are expected to get things resolved and help drive the priorities of the program.
>
>How were the priorities set?
>=====================
>Well, this is very well known; during the Summits, mini summits, various meetings, mailing list discussions, etc.
>
>What are the factors a driver must look into while providing feedback?
>=====================================================
>We are contributing to a Foundation that supports Open Source software. We promote Open Community discussions. Besides these important considerations, a thorough guideline for providing feedback is documented at [1].
>
>How do they help drive the program?
>============================
>*They provide feedback that help support the important paradigms of (open but in general) software evolution: Supportability, Maintainability, Elasticity, Scalability, Stability, etc.
>* They are proactive in providing feedback on different fronts: design patterns, OpenStack coherence, cross-project interactions, developer perspectives, operator perspectives, security perspective, testing, dependency, use-cases, adoptability that can include subset of  user research, market research, competition research, interoperability etc
>* They help prioritize the code that is planned to be reviewed in a cycle and sometimes take ownership of a spec to see it though by discussing with different groups, reviewers, cross project liaisons, meetings within and outside of the project.
>* More importantly they provide timely feedback of the specs that have been prioritized in the beginning of cycle and attempt to provide prudent feedback on other specs.
>
>While I see that some of the core reviewers help the project in many of the above aspects and are good candidates for drivers, being a driver is an added responsibility. We should make every effort to set the right expectations on the same and encourage great developers become core-reviewers without being bogged down by this added burden. Hence, we have a clear separation of concern and do not have a strong dependency on either of the responsibility.
>
>About the ability to scale and the ACLs on the specs:
>===========================================
>I have to agree that our feedback time and thoroughness has lacked severely for the past few cycles. However, we must note that the community is growing and sometimes we need to bear through the transition phase. We have had a mission statement change and a few related features are still spunkily trying to get merged. I am glad that you brought up the feedback time on the specs, as this also applies to the feedback time on feature-code. For example, Artifacts reviews did not get much attention from the existing set of core-reviewers. How do we solve that first? If we are going to scale drivers, we first need to commit to be able to review features that are earlier promised to land. Adding more features that come later on the priority list of the program with the help of a bigger driver team and not providing early feedback to top priority reviews doesn’t make much sense.
>
>Clarity and transparency:
>=====================
>Historically, the feedback has primarily been given at the summits and at mini-summits. Any strong objections have been sincerely discussed and I’ve been part of most of them over the last few years. So, personally I did not have issues around clarity and transparency of the feedback. I have seen any features that needed feedback from variety of groups have been discussed at the events like summit, mini-summit, video conferencing, etc. The invitations have been public and for events that have limited seats (like video conference), open notices have been given to help FCFS principle.
>Also, please do add timeliness in the feedback as a part of the concern. A few of the non-drivers have not provided timely feedback that has caused disgruntlement within subset of the community members. We need to resolve that. So, the takeaway looks like we need a priority list of the features that will be the focus of the cycle. We take the help of such committed drivers (who often provide great feedback outside of the specs as well) and help drive the program forward by making core reviewers aware of the needed reviews.
>
>I hope that answers your questions. I have attempted to jot this down very late in the night and may have missed some things; I apologize about the same. Please do raise any outstanding concerns and I will make best attempt in formulating the answers to the same in writing; some things are just intuitive and better communicated verbally :-)
>
>I appreciate your concern raised out in the open and touching very important points about our process. As an effervescent and dynamic community, we should plan to move towards a better process model & get something documented in this cycle and help clear any concerns for the members who are less frequent visitors to the ML.
>
>Looking forward to having such great conversations more often & across all OpenStack projects.
>
>[1] https://github.com/openstack/governance/blob/master/reference/new-projects-requirements.rst

I agree glance-drivers is another responsibility, which is why I said
that it'd be totally ok to just opt-out from doing it. I believe we're
just arguing whether we should let cores opt-in to drivers or just
opt-out from it.

TBH, I think core-reviewers should participate in the specs reviews
because it takes more than a spec to actually implement a feature and
sooner or later, reviewers will have to go back to the spec and read
it in order to provide a proper review to a patch.

Scaling drivers is not just a matter of adding more people to the
team, you also need to have a specific workflow that drivers can
follow in order to provide good reviews not just to the specs but to
the patches themselves.

In addition to this, there are specs that require patches to be
submitted to give a better understanding of what the feature is about.

That being said, if we look at the review/approval stats for our specs
repo, most of the approvals were done by the PTL, whereas the rest of
the team mostly did +2s and very few approvals that I didn't dug into
very much.

This basically shows that our review process for specs depends the PTL
approving them, which TBH I'm not fully against to. As a PTL, it is
good to have a good visibility of the things that are happening in the
project. Therefore, knowing what specs have been approved is
definitely a good thing.

The above plays nice with a broader set of reviewers that would
provide as much feedbacj to the specs as possible and then sync back
to the rest of the team or, at the very least, the PTL.

As I mentioned in one of my previous emails, we do this in oslo.* and
it's worked quite well, I believe. I personally trust our
core-reviewers team to have them all added to drivers and encourage
them to review the specs w/o approving.

In addition to that, each of our specs require a "core-reviewer" to be
added in the reviewers section. It makes little sense to me to have
core reviewers added to specs and those same reviewers not having a
voice/vote on the specs. Yes, they can comment, I know, but still.

I hope it's clearer where I'm coming from.
Cheers,
Flavio

>
>Best,
>-Nikhil
>
>________________________________________
>From: Flavio Percoco <flavio at redhat.com>
>Sent: Tuesday, April 21, 2015 4:34 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Glance] Open glance-drivers to all glance-cores
>
>On 20/04/15 19:34 +0000, Kuvaja, Erno wrote:
>>> -----Original Message-----
>>> From: Flavio Percoco [mailto:flavio at redhat.com]
>>> Sent: 20 April 2015 15:04
>>> To: openstack-dev at lists.openstack.org
>>> Subject: [openstack-dev] [Glance] Open glance-drivers to all glance-cores
>>>
>>> Hello Glance folks, and not Glance folks :D
>>>
>>> Here's a thought. I believe, based on the size of our
>>> project/community/reviewers team, we should just give access to all glance-
>>> cores to glance-drivers. Few considerations:
>>>
>>> 1) Many of our reviewers have been part of Glance even before I became
>>> part of it. It just makes no sense to me that these folks that have put efforts,
>>> time and that have helped making Glance what it is today don't have a voice
>>> on the specs. Commenting seems to not be enough, apparently.
>>>
>>> 2) I'd like to encourage a more open communication in our specs review
>>> process and including all our current *code* reviewers seems like a good
>>> step forward towards that. Things that I'd love to thing and to avoid are:
>>>
>>>   - I'd love to avoid all kind of private emails/conversations. Specs
>>>     can either be discussed in the review (which is what it's for),
>>>     team meetings or mailing list.
>>>
>>>   - I'd love for specs to get more attention from other folks. In
>>>     other words, I'd like to scale our specs review process. There are
>>>     specs that have sitten there for a bit.
>>>
>>>   - Our *code* reviewers know Glance's code, I want them to have a way
>>>     to express a stronger opinion/vote.
>>>
>>> 3) Although this doesn't seem to work for other projects, I believe Glance is
>>> not such a big community for this to fail. If anything, it should help us to
>>> manage the load a bit better. If there are core-reviewers that simply don't
>>> want to do spec reviews, that's fine.
>>>
>>> 4) If there are non-core reviewers that want to be part of the glance-drivers
>>> team then we can vote as we do for new cores. I have to admit that I'm
>>> having a hard time to imagine a case like this but...
>>> who knows? right?
>>>
>>> 5) It used to be like this and many of us just found themselves out of the
>>> glance-drivers team without notice. It's probably an unexpected side effect
>>> of disconnecting LP/gerrit and splitting the teams. Not a big deal, but...
>>>
>>> Thoughts?
>>> Flavio
>>>
>>> --
>>> @flaper87
>>> Flavio Percoco
>>
>>Hi Flavio,
>>
>>Thanks for your trust towards us. While I think this is great gesture (specially towards us new members) I do not think this is exactly the "safest" option at the moment. We have had active discussion and steep learning curve to the specs over past cycle and I think we need to sort that out first. Second concern I have is that looking our core-reviewers now, we are actually fairly young group since the last flush (give or take half of us have been even core less than a year).
>>
>>I will jump bit around on this so please try to hang on. For your point 3) I do agree. I think we can get there fairly soon if that is what people wants, but as mentioned I'd like to get our processes cleared first.
>>
>>I'd like to address points 4 and 5 on single hit and _if_ we in future include whole core in the drivers we keep the drivers group still separated and individual members to that group nominated on similar open manner as we do for our cores.
>>
>>Now last but not least to your point 2) (sorry, I have really no input on 1)). I do strongly agree with you on this.  As the specs are supposed to be not just an overview of the proposed functionality but also touched quite deeply to the technical aspects and as you pointed out that would be great to engage more of the code folks to the specs, there would be room for stronger opinion.
>>
>>What I would propose as alternative instead of including glance-core to glance-drivers would be change in the acls of the glance-specs repo. How about we give -2..+2 vote to glance-core & glance-drivers and keep the workflow +1 on glance-drivers only? This would give us stronger say on the direction but would keep the decision of taking the spec out of review (merge) on the drivers until we can figure out/agree and _document_ how we are going to process the specs.
>
>All good points and answers, Erno. Thanks!
>
>By reading your email, I believe we both are, somehow, complaining
>about our current spec review process. I believe it doesn't make sense
>that most of our historical reviewers are not in the drivers team and
>that their opinions are not *required* in some areas.
>
>Specs pretty much define *where* the project is headed and while I
>trust very much our current drivers team, I believe we need more
>input. It may be argued that to provide input it's not necessary to be
>in the team and have +2/-2 access but unfortunately, in some cases,
>it's not been enough.
>
>In Oslo, the oslo-core team is the one reviewing specs. The process,
>roughly, is that we all review the specs and vote and then the PTL
>approves it. I've followed this process in Glance too and I have not
>approved a single spec, I've limited myself to just review and provide
>feedback. Removing Workflow +/- could make sense but again, there are
>few cases where having a couple of more people watching over that repo
>is good.
>
>I guess my point is that specs will be discussed anyway and only
>people that have participated in the discussions for a specific spec
>know what's going on and what should be done. Therefore, I believe
>these people will keep shuch spec updated, the discussions open and
>what ever happens with that spec will be decided by more than one
>person. I'm, by any means, trying to imply anything here. I just want
>to make a point and encourage simplicity and clarity/transparency in
>our spec process.
>
>I trust the core team enough to believe no-one is going to get in
>approve mode on specs. ;)
>
>Flavio
>
>--
>@flaper87
>Flavio Percoco
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150423/d31a3bf6/attachment.pgp>