Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
On 07/31/2014 11:24 AM, Stefano Maffulli wrote: Given the amount of google juice that Ask OpeNStack gets, I'd suggest to ask those questions there and work on answers on that site. It's really effective at making information like this available. We can tag the questions and reference them in the wiki collectively. Anyone wants to get started asking there? I started it: https://ask.openstack.org/en/question/44327/how-long-should-i-wait-before-nudging-people-to-review-a-changeset/ Feel free to give answers there, please. thanks Stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
On 07/28/2014 01:51 AM, Thierry Carrez wrote: This is a great set of questions. When we have answers, we should consolidate them into a contributors expectations wiki page (in the same vein as the ML Etiquette one[1] or the Reviewers expectations one[2]) Given the amount of google juice that Ask OpeNStack gets, I'd suggest to ask those questions there and work on answers on that site. It's really effective at making information like this available. We can tag the questions and reference them in the wiki collectively. Anyone wants to get started asking there? thanks, stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
On 28 July 2014 11:37, Salvatore Orlando sorla...@nicira.com wrote: Therefore the likeness of your patch merging depends on the specific nature of the -1 you received. This is really a key point. Here is a pattern that's worth recognising: If your code is in reasonable shape but there is no urgent need to complete the merge then the reviewer might praise with faint damnation. That is, keep giving you -1 reviews for minor reasons until closer to the end of the merge window. If you are an overzealous newbie you might think you need to respond to every such comment with an immediate revision, and that you might then be rewarded with a +1, but then you would just be waving a dead chicken [0] and better advised to slow down a little. (Says me who went through 19 patch sets on his first small contribution :-)). I would hope that new contributors won't feel too much pressure to look busy. This can be a tough call when your job is to take all reasonable steps to have code accepted. It's one thing to be overzealous about answering nitpick reviews but it would be really unfortunate if you felt that you always needed to (extreme example) have an agenda item in all relevant weekly meetings e.g. NFV + Nova + Neutron + ML2 + Third party. In any case the whole process probably goes much more smoothly once you have a chance to attend a Summit and make some friends. That might not be bad as a first step for new contributors if they have that possibility. (But then the Summit is very expensive until after your first commit is merged and you are recognised as a contributor.) [0]: http://zvon.org/comp/r/ref-Jargon_file.html#Terms~wave_a_dead_chicken ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
Luke Gorrie a écrit : Here are some other topics that seem to take some time to develop a mental model of: How quickly and how often should you revise your patchset after a -1? (Is it better to give the community a week or so to collectively comment? Or should you revise ASAP after every negative review?) How do you know if your change is likely to merge? (If you have had 15 rounds of -1 votes and the last milestone deadline is a few days away, should you relax because your code is so thoroughly reviewed or should you despair because it should have been merged by now?) In the final days before a merge deadline, would it be rude to poke the person responsible for merging, or would it be negligent not to? How do you decide which IRC meetings to attend? (For meetings that occur at difficult times outside of working hours in your timezone, when are you expected to attend them? Is it okay to focus on email/informal communication if that suits you better and gets the job done?) If you're new to the project and you don't know anybody, who can you ask about this stuff? This is a great set of questions. When we have answers, we should consolidate them into a contributors expectations wiki page (in the same vein as the ML Etiquette one[1] or the Reviewers expectations one[2]) [1] https://wiki.openstack.org/wiki/MailingListEtiquette [2] https://wiki.openstack.org/wiki/ReviewChecklist We can't really assume a common culture anymore, so documenting shared understandings in our community is a critical step in maintaining cohesion in our virtual and global community. This is a space we need to work on in the near future -- thanks for raising that thread and reminding us we need to up our game there. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
For what is worth, I'm trying below to provide my perspective on Luke's question both as a reviewer and as developer. Salvatore On 26 July 2014 20:02, Luke Gorrie l...@snabb.co wrote: On 25 July 2014 20:05, Stefano Maffulli stef...@openstack.org wrote: Indeed, communication is key. I'm not sure how you envision to implement this though. We do send a message to first time contributors[1] to explain them how the review process works and give them very basic suggestions on how to react to comments (including what to do if things seem stuck). The main issue here though is that few people read emails, it's a basic fact of life. That welcome message does seem to do a really good job of setting expectations. Can you explain more what you have in mind? Here are some other topics that seem to take some time to develop a mental model of: How quickly and how often should you revise your patchset after a -1? (Is it better to give the community a week or so to collectively comment? Or should you revise ASAP after every negative review?) This is a very hard question to answer. From a developer perspective often you have tenths of outstanding patches, or the required changes translates into a need of redoing your patch from scratch, so quickly addressing a -1 is not possible. On the other hand, from a reviewer perspective, if there is too much time between two reviews then memory of previous reviews will be lost and the review process will basically begin again from scratch. Usually in order to help reviewers I try to be as pedant as possible in the commit message. I also add comments on the patch to help reviewers understand how I address their comments. This might help reviewers working on your patch, and avoid questions which, despite being legitimate, will just add more time to the review process for your patch. I try to ping core reviewers on IRC as less as possible, unless there is some sort of urgency from a community perspective. This is because I think all core reviewers have their own review queue, and are typically already working on sorting out reviews according to that queue. However, if you can identify a core reviewer which has reviewed several times your patch, then I guess it's ok to ping him directly, especially when you are at the last stages of the review cycle and your patch just needs a little push. How do you know if your change is likely to merge? (If you have had 15 rounds of -1 votes and the last milestone deadline is a few days away, should you relax because your code is so thoroughly reviewed or should you despair because it should have been merged by now?) If you have 15 -1 votes in just 1 round maybe you should consider abandoning your patch! Jokes apart, -1 has a whole set of meanings. As a core reviewer I can -1 because: - I think your approach is completely wrong and you should do your patch again from scratch - Your patch is ok but you should consider a more efficient implementation - Somebody else has done a patch like yours - The patch is ok but there are a few style/readability/maintainability nits to address - I have a possibly dumb question on the approach you've chosen and I would like to discuss that with you before approving Therefore the likeness of your patch merging depends on the specific nature of the -1 you received. I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. Regarding your specific question, if after 15 rounds you still have a -1 that means you have at least a core reviewer constantly following it, so you should probably be relaxed. In the final days before a merge deadline, would it be rude to poke the person responsible for merging, or would it be negligent not to? Poking is never rude. However, poking a reviewer is not a guarantee that your patch will be approved. The reviewer may add your patch to his/her queue, but it might still slip through the cracks. Most core reviewers two weeks before release time enter a review crunch period where it's not unlikely for them to look at 10 to 20 patches per day. How do you decide which IRC meetings to attend? (For meetings that occur at difficult times outside of working hours in your timezone, when are you expected to attend them? Is it okay to focus on email/informal communication if that suits you better and gets the job done?) Unfortunately there are too many meetings. I usually look at the agendas for the meetings where I can be remotely interested in. If there's a meeting where I think I have something to say, I will participate. Otherwise I will read the meeting minutes and logs. If you're new to the project and you don't know anybody, who can you ask about this stuff? I guess we'd just need to document that, but how this should be formalised is probably
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
On 25 July 2014 20:05, Stefano Maffulli stef...@openstack.org wrote: Indeed, communication is key. I'm not sure how you envision to implement this though. We do send a message to first time contributors[1] to explain them how the review process works and give them very basic suggestions on how to react to comments (including what to do if things seem stuck). The main issue here though is that few people read emails, it's a basic fact of life. That welcome message does seem to do a really good job of setting expectations. Can you explain more what you have in mind? Here are some other topics that seem to take some time to develop a mental model of: How quickly and how often should you revise your patchset after a -1? (Is it better to give the community a week or so to collectively comment? Or should you revise ASAP after every negative review?) How do you know if your change is likely to merge? (If you have had 15 rounds of -1 votes and the last milestone deadline is a few days away, should you relax because your code is so thoroughly reviewed or should you despair because it should have been merged by now?) In the final days before a merge deadline, would it be rude to poke the person responsible for merging, or would it be negligent not to? How do you decide which IRC meetings to attend? (For meetings that occur at difficult times outside of working hours in your timezone, when are you expected to attend them? Is it okay to focus on email/informal communication if that suits you better and gets the job done?) If you're new to the project and you don't know anybody, who can you ask about this stuff? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
Wow! These are the exact questions that I have struggled with. Thanks for stating them so clearly. Regards, Mandeep - On Sat, Jul 26, 2014 at 11:02 AM, Luke Gorrie l...@snabb.co wrote: On 25 July 2014 20:05, Stefano Maffulli stef...@openstack.org wrote: Indeed, communication is key. I'm not sure how you envision to implement this though. We do send a message to first time contributors[1] to explain them how the review process works and give them very basic suggestions on how to react to comments (including what to do if things seem stuck). The main issue here though is that few people read emails, it's a basic fact of life. That welcome message does seem to do a really good job of setting expectations. Can you explain more what you have in mind? Here are some other topics that seem to take some time to develop a mental model of: How quickly and how often should you revise your patchset after a -1? (Is it better to give the community a week or so to collectively comment? Or should you revise ASAP after every negative review?) How do you know if your change is likely to merge? (If you have had 15 rounds of -1 votes and the last milestone deadline is a few days away, should you relax because your code is so thoroughly reviewed or should you despair because it should have been merged by now?) In the final days before a merge deadline, would it be rude to poke the person responsible for merging, or would it be negligent not to? How do you decide which IRC meetings to attend? (For meetings that occur at difficult times outside of working hours in your timezone, when are you expected to attend them? Is it okay to focus on email/informal communication if that suits you better and gets the job done?) If you're new to the project and you don't know anybody, who can you ask about this stuff? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
On 24 July 2014 17:09, Kyle Mestery mest...@mestery.com wrote: 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. I have one idea for low-hanging fruit to put new contributors more at ease: to explain a little about both when and why the Merge button is finally pressed on a change. I mean so that new contributors won't have doubts like is it bad that my change isn't merged yet?, am I being too meek?, am I being too pushy?, have I missed a step somewhere?, how often should I skip dinner with my family to attend more/different IRC meetings?, and so on. I have had a good experience with this but that is many thanks to friendly people giving me informal feedback and reassurance outside of the Gerrit workflow and official docs. Cheers, -Luke ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
On Fri 25 Jul 2014 01:25:16 AM PDT, Luke Gorrie wrote: I have one idea for low-hanging fruit to put new contributors more at ease: to explain a little about both when and why the Merge button is finally pressed on a change. Indeed, communication is key. I'm not sure how you envision to implement this though. We do send a message to first time contributors[1] to explain them how the review process works and give them very basic suggestions on how to react to comments (including what to do if things seem stuck). The main issue here though is that few people read emails, it's a basic fact of life. Can you explain more what you have in mind? thanks, stef [1] http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/welcome_message.py ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
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. 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? 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:mest...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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. 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. 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:mest...@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
Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
-Original Message- From: Anita Kuno [mailto:ante...@anteaya.info] Sent: July-24-14 12:27 PM To: openstack-dev@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:mest...@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
