[openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
Alan Kavanagh
alan.kavanagh at ericsson.com
Fri Jul 25 03:18:02 UTC 2014
-----Original Message-----
From: Anita Kuno [mailto:anteaya at anteaya.info]
Sent: July-24-14 12:27 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
On 07/24/2014 11:50 AM, Alan Kavanagh wrote:
> Hi Kyle
>
> Thanks for taking the time for writing this note also I know this is not an easy discussion and not something being a matter of "waving hands or fingers". I believe what you have stated is well understood, though the main points I raised seems to be missing from this Neutron Policies wiki (interested to see if other projects have addressed and document this) such as (1) How to address when a contribution gets punted, (2) how to address BP's that are not progressing, (3)how to ensure that in the even a given BP/patch/etc gets no reviews how to address these. I feel this is around the Governance than just about the procedures and processes.
>
Hi Alan,
Let me add some thoughts here.
The listed items mostly boil down to communication.
Are those contributors with punted contributions in IRC channels? Do the attend the program weekly meeting? Many punted contributions, be they patches or blueprints, have the status they do because noone can find who the owners of these contributions are to ask them to fill in the gaps so reviewers even know what is being proposed.
AK--> to my understanding our folks have attended the weekly meetings as often as possible.
Now if folks don't know what channels to use or how to use IRC then that is an issue the we need to address, but having people available so reviewers can ask them about their offerings is a great first step and no I personally don't think that this is a governance issue.
If you want to find out what items are governance issues, do attend the TC weekly meeting:
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee and be sure to read the logs of past meetings:
http://eavesdrop.openstack.org/meetings/tc/
> Also, having more Core reviewers from different companies would also go a long way to helping to ensure that the different views and expectations are addressed community wide. I agree on the need to groom core reviewers, I guess what I miss here is the time it takes and how large would the Core Team grow, are their limits?
>
I agree that having diversity in core reviewers is very important. Core reviewers are those reviewers that have put in the time to do the reviews to demonstrate their commitment to the program. They also have enough experience with the program to gain the trust of other core reviewers. How long it takes is based on the individual reviewer. As for how large the team can grow, it is based on how many people want to do the work that it takes to gain that knowledge and experience.
AK--> It's a suggestion that works in other communities.
In short, it is up to the potential core reviewer.
Thanks Alan,
Anita.
> Kyle you are doing an amazing job, full commend you on that and believe you are definitely going beyond here to help out and its most appreciated. It would be good to get these points ironed out as they are lingering and having them addressed will help us going forward.
>
> BR
> Alan
>
> -----Original Message-----
> From: Kyle Mestery [mailto:mestery at mestery.com]
> Sent: July-24-14 11:10 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [neutron] [not-only-neutron] How to
> Contribute upstream in OpenStack Neutron
>
> I've received a lot of emails lately, mostly private, from people who feel they are being left out of the Neutron process. I'm unsure if other projects have people who feel this way, thus the uniquely worded subject above. I wanted to broadly address these concerns with this email.
>
> One thing I'd like to reiterate for people here, publicly on the list, is that there is no hidden agendas in Neutron, no political machines in the background working. As PTL, I've tried to be as transparent as possible. The honest reality is that if you want to have influence in Neutron or even in OpenStack in general, get involved upstream. Start committing small patches. Start looking at bugs. Participate in the weekly meetings. Build relationships upstream. Work across projects, not just Neutron. None of this is specific to Neutron or even OpenStack, but in fact is how you work in any upstream Open Source community.
>
> I'd also like to address the "add more core reviewers to solve all these problems" angle. While adding more core reviewers is a good thing, we need to groom core reviewers and meld them into the team.
> This takes time, and it's something we in Neutron actively work on.
> The process we use is documented here [1].
>
> I'd also like to point out that one of the things I've tried to do in Neutron as PTL during the Juno cycle is document as much of the process around working in Neutron. That is all documented on this wiki page here [2]. Feedback on this is most certainly welcome.
>
> I'm willing to help work with anyone who wants to contribute more to Neutron. I spend about half of my time doing just this already, between reviews, emails, and IRC conversations. So please feel free to find me on IRC (mestery on Freenode), on the ML, or even just use this email address.
>
> Thanks,
> Kyle
>
> [1] https://wiki.openstack.org/wiki/NeutronCore
> [2] https://wiki.openstack.org/wiki/NeutronPolicies
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list