Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/05/15 18:10, Adam Lawson wrote: I think the ATC thing came up as one avenue to explore when folks were trying to figure out ways to quantify Operator involvement for the purpose of identifying who are actively contributing to OpenStack versus those who are fans/users of OpenStack but don't have time right now to contribute more formally. ATC, BTC, CTC, DTC... there are several great ideas that were brought up as possibilities as well as some take-aways for further discussion at the Vancouver Summit and the talking points for the User Committee. I'm really crossing my fingers this translates into something noticeably unique starting with the next election. In my perfect world anyway. ; ) I am all for OTC (OpenStack / Operational Technical Contributor) :) -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Doug, it isn't about me or about trying to add more to the pool of one type of contributor from a different pool of individuals with a different skillset or about attempting to make shortcuts to leadership as you so delicately put it. Frankly I think you're missing the point. When there is a technical body governing everything of a technical nature within OpenStack and it consists of members from one slice of the overall community and candidates speak of engaging the operator community more than it has in the past as part of the reason folks should vote for them, I think the candidates are on point and we have an opportunity in front of us. Has nothing to do with broadening the pool of one specific type of contributor but about taking advantage of those who are already contributing in a different way. That's a strength in our community and when the tc appears to be moving towards technical leadership that paints with broader multi-discipline strokes, I'm completely on board with that. On May 5, 2015 6:07 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Excerpts from Adam Lawson's message of 2015-05-05 07:01:48 -0700: Doug, it isn't about me or about trying to add more to the pool of one type of contributor from a different pool of individuals with a different skillset or about attempting to make shortcuts to leadership as you so delicately put it. Frankly I think you're missing the point. When there is a technical body governing everything of a technical nature within OpenStack and it consists of members from one slice of the overall community and candidates speak of engaging the operator community more than it has in the past as part of the reason folks should vote for them, I think the candidates are on point and we have an opportunity in front of us. Has nothing to do with broadening the pool of one specific type of contributor but about taking advantage of those who are already contributing in a different way. That's a strength in our community and when the tc appears to be moving towards technical leadership that paints with broader multi-discipline strokes, I'm completely on board with that. Early on in the thread I thought you wanted community members without ATC status to be able to vote for and run for the TC. Maybe I misunderstood what you were saying? Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/05/15 16:01, Doug Hellmann wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Hi Doug. It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? Were bugs raised? Were blueprints submitted to make changes to accommodate any of these requests? Address any of them? Please don't tell me that you are waiting for the Operations people to submit all of these - because it is not going to happen. Most of them do not know how. So here is a process that breaks down. The info is there, but that information is not being followed through upon. Whose responsibility is this? The TC? The Foundation? The PTL's? Here we have proper feedback from those using the products, fighting with (not against) the products and trying to get it working. If even 10% of the items mentioned in these etherpads were addressed (or have a documented plan to be addressed in the future) then I will be very surprised. It comes down to this. OpenStack developers have a way of doing things. Operators also have a way of doing things - which is quite different to the way OpenStack does things. If each of these groups continue down the paths they are currently going - never shall the twain meet. They need to come towards each other. The OpenStack community needs be more receptive to the way Operators need things done. Operators need to be more receptive to the way things are done in OpenStack. Yes we have made progress. Yes we will continue to make progress. But until the Operators/users (and you can interchange users with Operators throughout my whole email - I was lazy) are accepted to be part of the decision process in OpenStack (and I think that you can agree - that if that actually happens today - it is way after the fact - or extremely late in the process) then this disconnect is going to continue. There is a feeling (at least that is my perception) that code is developed in a vacuum today. Without actually going into the field and asking what is needed - what is being used - what could be made better - before deciding what to write and fix. If you build it they will come[2] was a great idea in Hollywood, but I am not sure it will work as well for us - for OpenStack. Any ideas on how this could be solved - would be highly appreciated. [1] https://etherpad.openstack.org/p/PHL-ops-meetup [2] http://en.wikipedia.org/wiki/Field_of_Dreams -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
I think the ATC thing came up as one avenue to explore when folks were trying to figure out ways to quantify Operator involvement for the purpose of identifying who are actively contributing to OpenStack versus those who are fans/users of OpenStack but don't have time right now to contribute more formally. ATC, BTC, CTC, DTC... there are several great ideas that were brought up as possibilities as well as some take-aways for further discussion at the Vancouver Summit and the talking points for the User Committee. I'm really crossing my fingers this translates into something noticeably unique starting with the next election. In my perfect world anyway. ; ) *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Tue, May 5, 2015 at 7:59 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Adam Lawson's message of 2015-05-05 07:01:48 -0700: Doug, it isn't about me or about trying to add more to the pool of one type of contributor from a different pool of individuals with a different skillset or about attempting to make shortcuts to leadership as you so delicately put it. Frankly I think you're missing the point. When there is a technical body governing everything of a technical nature within OpenStack and it consists of members from one slice of the overall community and candidates speak of engaging the operator community more than it has in the past as part of the reason folks should vote for them, I think the candidates are on point and we have an opportunity in front of us. Has nothing to do with broadening the pool of one specific type of contributor but about taking advantage of those who are already contributing in a different way. That's a strength in our community and when the tc appears to be moving towards technical leadership that paints with broader multi-discipline strokes, I'm completely on board with that. Early on in the thread I thought you wanted community members without ATC status to be able to vote for and run for the TC. Maybe I misunderstood what you were saying? Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Excerpts from Maish Saidel-Keesing's message of 2015-05-05 18:00:15 +0300: On 05/05/15 16:01, Doug Hellmann wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Hi Doug. It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. Unfortunately I wasn't able to attend, either, but I've heard the same general sentiments of the results. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. +1 for writing things down I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? Were bugs raised? Were blueprints submitted to make changes to accommodate any of these requests? Address any of them? Please don't tell me that you are waiting for the Operations people to submit all of these - because it is not going to happen. Most of them do not know how. I don't expect them to file blueprints for new features, because the contributor responsible for the implementation needs to document their plans. I absolutely *do* expect Operators to file bugs, though, just as they would with any other software package they use. So here is a process that breaks down. The info is there, but that information is not being followed through upon. Whose responsibility is this? The TC? The Foundation? The PTL's? Here we have proper feedback from those using the products, fighting with (not against) the products and trying to get it working. If even 10% of the items mentioned in these etherpads were addressed (or have a documented plan to be addressed in the future) then I will be very surprised. OK, so we're finally getting to the real issues! :-) What is your expectation for timing? Having a meetup to collect feedback like this mid-cycle is unlikely to affect the current release in significant ways. For example, bugs may be prioritized differently, and I know some were, but we're not likely to stop work on features already in progress to work on something new or start any large new initiatives at that point in the cycle. Is the feedback being taken into account during planning for liberty? Has someone correlated the feedback with the proposed specs and summit sessions? This is normally something I would expect the PTLs to be involved with for individual projects, although it might help to have a single document listing desired actionable changes from those separate etherpads, and someone involved in the meeting is probably better able to do that -- it can be difficult to look at meeting logs after the fact and extract a summary if you weren't in the room when the meeting occurred. Are there summaries of the consensus from the meetings? Looking through a few of the etherpads: https://etherpad.openstack.org/p/PHL-ops-burning-issues The first few items in the burning issues session look immediately actionable, some of them (such as nova-net/neutron migration and ceilometer performance improvements) are already under way as long-term changes, but some of them
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Thiery - Most operators are busy fighting operational battles, scale out etc. It is often an all-hands-on-the-deck job. I don’t think we should just measure by contributors getting work done. The work is often silent, and lags behind the dev cycle. Subbu On May 4, 2015, at 9:25 AM, Thierry Carrez thie...@openstack.org wrote: But in the end, it all boils down to contributors that get the work done and therefore make it going in one direction or another. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Le 05/05/2015 18:00, Thierry Carrez a écrit : Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. Could we please stop to consider Ops and Devs as distinct groups of people ? Some Ops are also contributing to bugfixing or documentation, and some devs are also internal ops for their own company cloud. We're far from a world where people are not speaking the same language. They do, and OpenStack is so big that by some extend, Ops need to understand code and Devs need to understand Ops. At least one good opportunity for seeing how things are is just to attend an Upstream Training course and see the audience. In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/05/15 19:14, Sylvain Bauza wrote: Le 05/05/2015 18:00, Thierry Carrez a écrit : Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. Could we please stop to consider Ops and Devs as distinct groups of people ? Some Ops are also contributing to bugfixing or documentation, and some devs are also internal ops for their own company cloud. We're far from a world where people are not speaking the same language. They do, and OpenStack is so big that by some extend, Ops need to understand code and Devs need to understand Ops. Completely Agree!! At least one good opportunity for seeing how things are is just to attend an Upstream Training course and see the audience. And perhaps it could also be a good idea to have developers deploy and operate a highly available geographically dispersed OpenStack implementation trying to adhere to a defined SLA? It should go both ways. In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
I think that this will be my last say on this matter, because it seems to be getting out of hand. Us vs. them. Dev vs. Ops. It could be perceived that I am trying to wage a 'war' on the OpenStack development process, on the Developers, but that is not the case. But I do think there are valid points from both sides that need to be addressed. There are two sides of this story and in the end I do think that OpenStack as a community does need to accommodate and cater to the needs of of the colors of the rainbow. I hope that this discussion does open some doors, opens some minds and creates acceptance for those who are not like us. Believe me I have been dealing with this all my life. I would like to thank you all for your contribution and thoughts in this thread, I hope it was useful for you all as it was for me. -- Best Regards, Maish Saidel-Keesing On 05/04/15 20:11, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-05-04 17:46:21 +0300: On 05/04/15 17:07, Anita Kuno wrote: I'd like to go back to the beginning to clarify something. On 04/29/2015 02:34 PM, Adam Lawson wrote: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community In my statements I talked about acknowledging the operator community not representing them. When I speak, I represent myself and my best understanding of a certain situation, if others find value in the position I hold, they will let me know. In my view of what comprises OpenStack, the TC is one point of a triangle and the operators are an entirely different point. Trying to get two points of a triangle to be the same thing compromises the integrity of the structure. Each needs to play its part, not try to be something it is not. A three point triangle. I like the idea! Anita I assume that you are talking about the TC[3], the board [1] and the user committee [2]. I honestly do not see this at the moment as an equally weighted triangle. Should they be? Perhaps not, maybe yes. It could be that my view of things is skew, but here it is. The way to get something into OpenStack is through code. Who submits the code? Developers. Who approves code? Reviewers and core On top of that you have the PTL Above the PTL - you have the TC. They decide what is added into OpenStack and (are supposed) drive overall direction. These are the people that have actionable influence into what goes into the products. AFAIK neither the Foundation - nor the User committee have any actionable influence into what goes into the products, what items are prioritized and what is dropped. If each of the three point of the triangle had proper (actionable) influence and (actionable) say in what goes on and happens within the OpenStack then that would be ideal. Does the representation have to be equal? I don't think so. But it should be there somehow. One of the points of the User Committee mission is: Consolidate user requirements and present these to the management board and technical committee There is no mention that I could find on any of the other missions[3][1] that says that the TC or the board have to do anything with user requirements presented to them. I do not know if this has ever been addressed before, but it should be defined. A process with where the TC and collects requirements from the User Committee or Board and with a defined process this trickles down into the teams and projects. You're describing these relationships in a much more hierarchical manner than I think reflects their reality. Decisions about the future of OpenStack are made by the people who show up and contribute. We try to identify common goals and priorities, and where there's little overlap we support each other in ways that we perceive improve the project. That process uses input from many sources, including product managers from contributing companies and operator/user feedback. As Thierry pointed out, there's no community group dictating what anyone works on or what the priorities are. Again, I'm curious about the specific issues driving this discussion. Are there bugs or blueprints that you feel need more attention? Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Le 05/05/2015 18:41, Maish Saidel-Keesing a écrit : On 05/05/15 19:14, Sylvain Bauza wrote: Le 05/05/2015 18:00, Thierry Carrez a écrit : Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. Could we please stop to consider Ops and Devs as distinct groups of people ? Some Ops are also contributing to bugfixing or documentation, and some devs are also internal ops for their own company cloud. We're far from a world where people are not speaking the same language. They do, and OpenStack is so big that by some extend, Ops need to understand code and Devs need to understand Ops. Completely Agree!! At least one good opportunity for seeing how things are is just to attend an Upstream Training course and see the audience. And perhaps it could also be a good idea to have developers deploy and operate a highly available geographically dispersed OpenStack implementation trying to adhere to a defined SLA? It should go both ways. As I said, I don't understand why you consider that devs are not production aware ? I can't speak for everyone but I certainly trust that most of the developers are part of a company which either is a software vendor (and consequently has customer requests) or is directly running a production cloud. Some of us have also stories where they were previously Ops but then moved to a developing position just because they began to contribute to OpenStack directly, as I mentioned. -Sylvain In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On Tue, May 5, 2015 at 11:41 AM, Maish Saidel-Keesing mais...@maishsk.com wrote: And perhaps it could also be a good idea to have developers deploy and operate a highly available geographically dispersed OpenStack implementation trying to adhere to a defined SLA? Many do. Don't forget that the two original projects that formed OpenStack were both from active deployments, one of which is still around and very active in the community in many ways. Most of the top contributors in terms of commits and code are from companies that are either operators themselves or directly support operators as a paid service. That said, there are also conflicting priorities as some companies and operators are focused on serving different markets and user bases. It seems like much of the division on priorities and implementation of operator-requested needs may be due to the perceptions caused by differing priorities? dt -- Dean Troyer dtro...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/05/15 19:00, Thierry Carrez wrote: Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. Quite the contrary - I do not live in a Ops vs. Dev world. What I am trying to do here is help both sides understand each other. Because there should be no us vs. them thing here. It should be an us thing. But an ALL of us thing. In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. +1 here! -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/05/15 19:22, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-05-05 18:00:15 +0300: On 05/05/15 16:01, Doug Hellmann wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Hi Doug. It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. Unfortunately I wasn't able to attend, either, but I've heard the same general sentiments of the results. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. +1 for writing things down I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? Were bugs raised? Were blueprints submitted to make changes to accommodate any of these requests? Address any of them? Please don't tell me that you are waiting for the Operations people to submit all of these - because it is not going to happen. Most of them do not know how. I don't expect them to file blueprints for new features, because the contributor responsible for the implementation needs to document their plans. I absolutely *do* expect Operators to file bugs, though, just as they would with any other software package they use. And I sincerely hope that they continue. So here is a process that breaks down. The info is there, but that information is not being followed through upon. Whose responsibility is this? The TC? The Foundation? The PTL's? Here we have proper feedback from those using the products, fighting with (not against) the products and trying to get it working. If even 10% of the items mentioned in these etherpads were addressed (or have a documented plan to be addressed in the future) then I will be very surprised. OK, so we're finally getting to the real issues! :-) What is your expectation for timing? Having a meetup to collect feedback like this mid-cycle is unlikely to affect the current release in significant ways. For example, bugs may be prioritized differently, and I know some were, but we're not likely to stop work on features already in progress to work on something new or start any large new initiatives at that point in the cycle. If that process could be a transparent and published - I am sure that will beneficial for everyone Is the feedback being taken into account during planning for liberty? Has someone correlated the feedback with the proposed specs and summit sessions? This is normally something I would expect the PTLs to be involved with for individual projects, although it might help to have a single document listing desired actionable changes from those separate etherpads, and someone involved in the meeting is probably better able to do that -- it can be difficult to look at meeting logs after the fact and extract a summary if you weren't in the room when the meeting occurred. Are there summaries of the consensus from the meetings? Looking through a few of the etherpads: https://etherpad.openstack.org/p/PHL-ops-burning-issues The first few items in the burning issues session look immediately actionable, some of them (such as nova-net/neutron migration and
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Excerpts from Maish Saidel-Keesing's message of 2015-05-05 19:52:24 +0300: On 05/05/15 19:22, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-05-05 18:00:15 +0300: On 05/05/15 16:01, Doug Hellmann wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Hi Doug. It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. Unfortunately I wasn't able to attend, either, but I've heard the same general sentiments of the results. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. +1 for writing things down I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? Were bugs raised? Were blueprints submitted to make changes to accommodate any of these requests? Address any of them? Please don't tell me that you are waiting for the Operations people to submit all of these - because it is not going to happen. Most of them do not know how. I don't expect them to file blueprints for new features, because the contributor responsible for the implementation needs to document their plans. I absolutely *do* expect Operators to file bugs, though, just as they would with any other software package they use. And I sincerely hope that they continue. So here is a process that breaks down. The info is there, but that information is not being followed through upon. Whose responsibility is this? The TC? The Foundation? The PTL's? Here we have proper feedback from those using the products, fighting with (not against) the products and trying to get it working. If even 10% of the items mentioned in these etherpads were addressed (or have a documented plan to be addressed in the future) then I will be very surprised. OK, so we're finally getting to the real issues! :-) What is your expectation for timing? Having a meetup to collect feedback like this mid-cycle is unlikely to affect the current release in significant ways. For example, bugs may be prioritized differently, and I know some were, but we're not likely to stop work on features already in progress to work on something new or start any large new initiatives at that point in the cycle. If that process could be a transparent and published - I am sure that will beneficial for everyone Most of the contributor teams meet weekly on IRC, and discuss priorities in the meeting, here on the mailing list, on the bug reports, on reviews, etc. -- the usual places. On top of that, the PTLs and release management team work hard to publish information about the status of blueprints over the course of the cycle. Is the problem that you don't know where we're publishing the information already, or is it in a form that's not easy to understand, or is there something else about the current process that makes what is already being written unsuitable for your needs? Is the feedback being taken into account during planning for liberty?
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 5/5/15, 6:52 PM, Maish Saidel-Keesing mais...@maishsk.com wrote: On 05/05/15 19:22, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-05-05 18:00:15 +0300: On 05/05/15 16:01, Doug Hellmann wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: ups continue down the paths they are currently going - never shall the twain meet. They need to come towards each other. The OpenStack community needs be more receptive to the way Operators need things done. Operators need to be more receptive to the way things are done in OpenStack. Yes we have made progress. Yes we will continue to make progress. But until the Operators/users (and you can interchange users with Operators throughout my whole email - I was lazy) are accepted to be part of the decision process in OpenStack (and I think that you can agree - that if that actually happens today - it is way after the fact - or extremely late in the process) then this disconnect is going to continue. Yes, I think we all want operator and user input to be included much earlier in the process. It remains to be seen if the TC is the right group to address those concerns directly, since we tend to deal with issues that affect all projects rather than individual projects. That said, there is certainly still a gap in expectations for how feedback should be handled, and there's work to do to collect it and make sure the right audience sees it, and helping to develop the process to facilitate that communication may be something for the TC to take on. So how do we bridge this gap and get the feedback added earlier in the development cycle? And of course the obvious question - with whom does this responsibility lie? Let¹s not underestimate how far we¹ve come in the past 18 months. Ops meetups have gone from the first with around 40 people to over 200 in Paris. A single stream meeting in San Jose has gone to over 50 Ops sessions at Vancouver. The specs process has given a way for the right improvements to be made. We have now done 4 in-place upgrades in CERN's production cloud thanks to the efforts of the various OpenStack projects to make these activities easier while maintaining compatibility for 1000s of usersŠ I don¹t write lengthy blogs on upgrades anymore since the documentation covers how to do it Š. This is seriously hard work by all concerned which has given major improvements compared to Folsom days... The product working group has not been mentioned in this discussion so far. It has potential to help to address the questions which often arise when there are enhancements being requested but no resources to focus on them or address them. While there are some people running clouds who also contribute code, many have neither the skills or knowledge to make the commits into the upstream versions. As many companies go through the cloud transformation, helping the organisation's end users and changing the way we deliver IT services is very time consuming. I find it very encouraging that the product working group are looking to have some people in the major sessions to consolidate some of the ideas into actionable blueprints. This is a major contribution by the companies working on OpenStack to bridge the etherpad-blueprint which requires many perspectives (such as funding justification). At Vancouver, we have the chance to have a single design summit. This should allow people to move more quickly between sessions with aligned timetables and location. User committee governance fans are welcome to bring their ideas to https://etherpad.openstack.org/p/YVR-ops-user-committee. I have been noting down the various points from the recent threads into the ether pad but feel free to add anything further as you wish. The bylaws give a lot of flexibility for the user committee but we also need to be realistic that many of the potential electorate have delivering value to their organisations as their objective. Tim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Morgan Fainberg wrote: On Friday, May 1, 2015, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 05/01/2015 02:22 PM, Tim Bell wrote: The spec review process has made it much easier for operators to see what is being proposed and give input. Recognition is a different topic. It also comes into who would be the operator/user electorate ? ATC is simple to define where the equivalent operator/user definition is less clear. I think spec review participation is a great example of where it would make sense to grant extra ATC status. If someone provides valuable spec input, but hasn't made any commits that get ATC status, I'd vote to approve their ATC status if proposed. This is exactly the case for David Chadwick (U of Kent) if anyone is looking for prior examples of someone who has contributed to the spec process but has not landed code and has received ATC for the contributions. This is a great way to confer ATC for spec participation. I think we are still bound by the Foundation bylaws and should not completely merge the User Committee and Technical Committee mandates. That said, I think operators contributions need to be recognized as such. So we can probably follow a strategy in three directions: * Continue to encourage operators to participate in spec review, code tryouts etc. * Encourage developers to recognize significant input from operators as co-authorship of a feature (like Keystone did with David) -- which would lead to more operators being ATC * Develop the User Committee -- go beyond organizing the user survey and really be the representative body of operators. That may involve finding a way to identify operators so that they can participate in elections there (and therefore feel represented). My point being... operating OpenStack is different from contributing to OpenStack development. Both activities are valuable and necessary, but they are separate activities, represented by separate committees. Some people do both, by providing essential operator feedback during feature design (let's call them contributing operators) -- those people are awesome and should definitely be recognized on *both* sides. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
I'd like to go back to the beginning to clarify something. On 04/29/2015 02:34 PM, Adam Lawson wrote: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community In my statements I talked about acknowledging the operator community not representing them. When I speak, I represent myself and my best understanding of a certain situation, if others find value in the position I hold, they will let me know. In my view of what comprises OpenStack, the TC is one point of a triangle and the operators are an entirely different point. Trying to get two points of a triangle to be the same thing compromises the integrity of the structure. Each needs to play its part, not try to be something it is not. There have been many helpful comments on how those operators who wish to contribute to reviews, patches and specs as well as receive ATC status may do so, for those operators who wish to be acknowledged as contributors as well as being operators. Operators have a very useful, very valuable, very necessary perspective that is not a developer's perspective that needs to be heard and communicated. Thierry has made the suggestion that a strong User Committee representing the voice of the operator would be a good direction here. I support this suggestion. Tim Bell is working on an etherpad here: https://etherpad.openstack.org/p/YVR-ops-user-committee Thank you Adam, Anita. who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) Is it be feasible to start allowing the operator community to also cast votes for TC candidates? Is the TC *only* addressing technical concerns that are relevant to the development community? Since the TC candidates are embracing the idea of representing more than just the developer community, it would /seem/ the voters electing the TC members should include the communities being represented. If the TC only addresses developer concerns, it would seem they become at risk of losing touch with the operator/architecture/user concerns because the operator community voice is never heard in the voting booth. Perhaps this bumps into how it used to be versus how it should be. I don't know. Just struck me as incongruent with the platform of almost every candidate - broadening representation while the current rules prohibit that level of co-participation. Thoughts? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/04/15 17:07, Anita Kuno wrote: I'd like to go back to the beginning to clarify something. On 04/29/2015 02:34 PM, Adam Lawson wrote: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community In my statements I talked about acknowledging the operator community not representing them. When I speak, I represent myself and my best understanding of a certain situation, if others find value in the position I hold, they will let me know. In my view of what comprises OpenStack, the TC is one point of a triangle and the operators are an entirely different point. Trying to get two points of a triangle to be the same thing compromises the integrity of the structure. Each needs to play its part, not try to be something it is not. A three point triangle. I like the idea! Anita I assume that you are talking about the TC[3], the board [1] and the user committee [2]. I honestly do not see this at the moment as an equally weighted triangle. Should they be? Perhaps not, maybe yes. It could be that my view of things is skew, but here it is. The way to get something into OpenStack is through code. Who submits the code? Developers. Who approves code? Reviewers and core On top of that you have the PTL Above the PTL - you have the TC. They decide what is added into OpenStack and (are supposed) drive overall direction. These are the people that have actionable influence into what goes into the products. AFAIK neither the Foundation - nor the User committee have any actionable influence into what goes into the products, what items are prioritized and what is dropped. If each of the three point of the triangle had proper (actionable) influence and (actionable) say in what goes on and happens within the OpenStack then that would be ideal. Does the representation have to be equal? I don't think so. But it should be there somehow. One of the points of the User Committee mission is: Consolidate user requirements and present these to the management board and technical committee There is no mention that I could find on any of the other missions[3][1] that says that the TC or the board have to do anything with user requirements presented to them. I do not know if this has ever been addressed before, but it should be defined. A process with where the TC and collects requirements from the User Committee or Board and with a defined process this trickles down into the teams and projects. My 0.02 Shekels. There have been many helpful comments on how those operators who wish to contribute to reviews, patches and specs as well as receive ATC status may do so, for those operators who wish to be acknowledged as contributors as well as being operators. Operators have a very useful, very valuable, very necessary perspective that is not a developer's perspective that needs to be heard and communicated. Thierry has made the suggestion that a strong User Committee representing the voice of the operator would be a good direction here. I support this suggestion. Tim Bell is working on an etherpad here: https://etherpad.openstack.org/p/YVR-ops-user-committee Thank you Adam, Anita. who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) Is it be feasible to start allowing the operator community to also cast votes for TC candidates? Is the TC *only* addressing technical concerns that are relevant to the development community? Since the TC candidates are embracing the idea of representing more than just the developer community, it would /seem/ the voters electing the TC members should include the communities being represented. If the TC only addresses developer concerns, it would seem they become at risk of losing touch with the operator/architecture/user concerns because the operator community voice is never heard in the voting booth. Perhaps this bumps into how it used to be versus how it should be. I don't know. Just struck me as incongruent with the platform of almost every candidate - broadening representation while the current rules prohibit that level of co-participation. Thoughts? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 [1] https://wiki.openstack.org/wiki/Governance/Foundation/Mission [2] https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee [3] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee -- Best Regards, Maish Saidel-Keesing
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/04/2015 10:46 AM, Maish Saidel-Keesing wrote: On 05/04/15 17:07, Anita Kuno wrote: I'd like to go back to the beginning to clarify something. On 04/29/2015 02:34 PM, Adam Lawson wrote: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community In my statements I talked about acknowledging the operator community not representing them. When I speak, I represent myself and my best understanding of a certain situation, if others find value in the position I hold, they will let me know. In my view of what comprises OpenStack, the TC is one point of a triangle and the operators are an entirely different point. Trying to get two points of a triangle to be the same thing compromises the integrity of the structure. Each needs to play its part, not try to be something it is not. A three point triangle. I like the idea! Anita I assume that you are talking about the TC[3], the board [1] and the user committee [2]. No that wasn't what I meant. You seem to be making a point so I won't detract from your point, except to clarify that was not my meaning. Thanks, Anita. I honestly do not see this at the moment as an equally weighted triangle. Should they be? Perhaps not, maybe yes. It could be that my view of things is skew, but here it is. The way to get something into OpenStack is through code. Who submits the code? Developers. Who approves code? Reviewers and core On top of that you have the PTL Above the PTL - you have the TC. They decide what is added into OpenStack and (are supposed) drive overall direction. These are the people that have actionable influence into what goes into the products. AFAIK neither the Foundation - nor the User committee have any actionable influence into what goes into the products, what items are prioritized and what is dropped. If each of the three point of the triangle had proper (actionable) influence and (actionable) say in what goes on and happens within the OpenStack then that would be ideal. Does the representation have to be equal? I don't think so. But it should be there somehow. One of the points of the User Committee mission is: Consolidate user requirements and present these to the management board and technical committee There is no mention that I could find on any of the other missions[3][1] that says that the TC or the board have to do anything with user requirements presented to them. I do not know if this has ever been addressed before, but it should be defined. A process with where the TC and collects requirements from the User Committee or Board and with a defined process this trickles down into the teams and projects. My 0.02 Shekels. There have been many helpful comments on how those operators who wish to contribute to reviews, patches and specs as well as receive ATC status may do so, for those operators who wish to be acknowledged as contributors as well as being operators. Operators have a very useful, very valuable, very necessary perspective that is not a developer's perspective that needs to be heard and communicated. Thierry has made the suggestion that a strong User Committee representing the voice of the operator would be a good direction here. I support this suggestion. Tim Bell is working on an etherpad here: https://etherpad.openstack.org/p/YVR-ops-user-committee Thank you Adam, Anita. who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) Is it be feasible to start allowing the operator community to also cast votes for TC candidates? Is the TC *only* addressing technical concerns that are relevant to the development community? Since the TC candidates are embracing the idea of representing more than just the developer community, it would /seem/ the voters electing the TC members should include the communities being represented. If the TC only addresses developer concerns, it would seem they become at risk of losing touch with the operator/architecture/user concerns because the operator community voice is never heard in the voting booth. Perhaps this bumps into how it used to be versus how it should be. I don't know. Just struck me as incongruent with the platform of almost every candidate - broadening representation while the current rules prohibit that level of co-participation. Thoughts? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 [1]
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Maish Saidel-Keesing wrote: A three point triangle. I like the idea! Anita I assume that you are talking about the TC[3], the board [1] and the user committee [2]. I honestly do not see this at the moment as an equally weighted triangle. Should they be? Perhaps not, maybe yes. It could be that my view of things is skew, but here it is. The way to get something into OpenStack is through code. Who submits the code? Developers. Who approves code? Reviewers and core On top of that you have the PTL Above the PTL - you have the TC. They decide what is added into OpenStack and (are supposed) drive overall direction. These are the people that have actionable influence into what goes into the products. AFAIK neither the Foundation - nor the User committee have any actionable influence into what goes into the products, what items are prioritized and what is dropped. That's simply acknowledging the mechanics of an open source / open innovation project like OpenStack. Having the Board or the User committee decide what goes into the products, what items are prioritized and what is dropped won't make it magically happen. At the end of the day, you need a contributor willing to write, review, prioritize that code. The contributors to an open source project ultimately make things go in the open source project. They can be (and should be) influenced by outside input, especially users of the project. Companies can influence what is being worked on by funding developers to work on specific things. But in the end, it all boils down to contributors that get the work done and therefore make it going in one direction or another. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Excerpts from Maish Saidel-Keesing's message of 2015-05-04 17:46:21 +0300: On 05/04/15 17:07, Anita Kuno wrote: I'd like to go back to the beginning to clarify something. On 04/29/2015 02:34 PM, Adam Lawson wrote: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community In my statements I talked about acknowledging the operator community not representing them. When I speak, I represent myself and my best understanding of a certain situation, if others find value in the position I hold, they will let me know. In my view of what comprises OpenStack, the TC is one point of a triangle and the operators are an entirely different point. Trying to get two points of a triangle to be the same thing compromises the integrity of the structure. Each needs to play its part, not try to be something it is not. A three point triangle. I like the idea! Anita I assume that you are talking about the TC[3], the board [1] and the user committee [2]. I honestly do not see this at the moment as an equally weighted triangle. Should they be? Perhaps not, maybe yes. It could be that my view of things is skew, but here it is. The way to get something into OpenStack is through code. Who submits the code? Developers. Who approves code? Reviewers and core On top of that you have the PTL Above the PTL - you have the TC. They decide what is added into OpenStack and (are supposed) drive overall direction. These are the people that have actionable influence into what goes into the products. AFAIK neither the Foundation - nor the User committee have any actionable influence into what goes into the products, what items are prioritized and what is dropped. If each of the three point of the triangle had proper (actionable) influence and (actionable) say in what goes on and happens within the OpenStack then that would be ideal. Does the representation have to be equal? I don't think so. But it should be there somehow. One of the points of the User Committee mission is: Consolidate user requirements and present these to the management board and technical committee There is no mention that I could find on any of the other missions[3][1] that says that the TC or the board have to do anything with user requirements presented to them. I do not know if this has ever been addressed before, but it should be defined. A process with where the TC and collects requirements from the User Committee or Board and with a defined process this trickles down into the teams and projects. You're describing these relationships in a much more hierarchical manner than I think reflects their reality. Decisions about the future of OpenStack are made by the people who show up and contribute. We try to identify common goals and priorities, and where there's little overlap we support each other in ways that we perceive improve the project. That process uses input from many sources, including product managers from contributing companies and operator/user feedback. As Thierry pointed out, there's no community group dictating what anyone works on or what the priorities are. Again, I'm curious about the specific issues driving this discussion. Are there bugs or blueprints that you feel need more attention? Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. I also liked your suggestions earlier about potential ways to implement. On May 4, 2015 9:31 AM, Thierry Carrez thie...@openstack.org wrote: Maish Saidel-Keesing wrote: A three point triangle. I like the idea! Anita I assume that you are talking about the TC[3], the board [1] and the user committee [2]. I honestly do not see this at the moment as an equally weighted triangle. Should they be? Perhaps not, maybe yes. It could be that my view of things is skew, but here it is. The way to get something into OpenStack is through code. Who submits the code? Developers. Who approves code? Reviewers and core On top of that you have the PTL Above the PTL - you have the TC. They decide what is added into OpenStack and (are supposed) drive overall direction. These are the people that have actionable influence into what goes into the products. AFAIK neither the Foundation - nor the User committee have any actionable influence into what goes into the products, what items are prioritized and what is dropped. That's simply acknowledging the mechanics of an open source / open innovation project like OpenStack. Having the Board or the User committee decide what goes into the products, what items are prioritized and what is dropped won't make it magically happen. At the end of the day, you need a contributor willing to write, review, prioritize that code. The contributors to an open source project ultimately make things go in the open source project. They can be (and should be) influenced by outside input, especially users of the project. Companies can influence what is being worked on by funding developers to work on specific things. But in the end, it all boils down to contributors that get the work done and therefore make it going in one direction or another. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/04/2015 01:11 PM, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-05-04 17:46:21 +0300: On 05/04/15 17:07, Anita Kuno wrote: I'd like to go back to the beginning to clarify something. On 04/29/2015 02:34 PM, Adam Lawson wrote: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community In my statements I talked about acknowledging the operator community not representing them. When I speak, I represent myself and my best understanding of a certain situation, if others find value in the position I hold, they will let me know. In my view of what comprises OpenStack, the TC is one point of a triangle and the operators are an entirely different point. Trying to get two points of a triangle to be the same thing compromises the integrity of the structure. Each needs to play its part, not try to be something it is not. A three point triangle. I like the idea! Anita I assume that you are talking about the TC[3], the board [1] and the user committee [2]. I honestly do not see this at the moment as an equally weighted triangle. Should they be? Perhaps not, maybe yes. It could be that my view of things is skew, but here it is. The way to get something into OpenStack is through code. Who submits the code? Developers. Who approves code? Reviewers and core On top of that you have the PTL Above the PTL - you have the TC. They decide what is added into OpenStack and (are supposed) drive overall direction. These are the people that have actionable influence into what goes into the products. AFAIK neither the Foundation - nor the User committee have any actionable influence into what goes into the products, what items are prioritized and what is dropped. If each of the three point of the triangle had proper (actionable) influence and (actionable) say in what goes on and happens within the OpenStack then that would be ideal. Does the representation have to be equal? I don't think so. But it should be there somehow. One of the points of the User Committee mission is: Consolidate user requirements and present these to the management board and technical committee There is no mention that I could find on any of the other missions[3][1] that says that the TC or the board have to do anything with user requirements presented to them. I do not know if this has ever been addressed before, but it should be defined. A process with where the TC and collects requirements from the User Committee or Board and with a defined process this trickles down into the teams and projects. You're describing these relationships in a much more hierarchical manner than I think reflects their reality. Decisions about the future of OpenStack are made by the people who show up and contribute. We try to identify common goals and priorities, and where there's little overlap we support each other in ways that we perceive improve the project. That process uses input from many sources, including product managers from contributing companies and operator/user feedback. As Thierry pointed out, there's no community group dictating what anyone works on or what the priorities are. I think that's the dead on point. You get other people to help with features / fixes not because they are told to, but because they also believe them to be important / exciting. Being a PTL or on the TC gives you a slightly larger soapbox, however I'd argue that typically the individual earned the larger soapbox first, and becoming PTL / TC was the effect of having built credibility and influence, not the cause. This is the nature of collaborative open development. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 2015-05-04 10:25:10 -0700 (-0700), Adam Lawson wrote: [...] it's pretty rare to see project teams led and governed by only developers. [...] Not sure what other free software projects you've worked on/with before but not only is it not rare, it's the vast majority of them. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Davanum Srinivas wrote: One concrete suggestion based on my experience working with Kris Lindgren on Heartbeat patch: http://markmail.org/message/gifrt5f3mslco24j I could have added a Co-Tested-By (or Co-Operator - get it? :) in my commit message which would have signaled a concrete contribution/feedback with specific folks in the operator community. This could be done not just for code, could be for reviews or documentation etc as well. WDYT? +1 Kris is a great example, and I can think of other operators that should be some sort of ATC (but may not contribute code to get this). IMHO any operator running openstack (let's say at least at 50+ compute nodes) and operating it should get full access to the summit, because their words of advice/experience are just as useful as technical contributors... thanks, dims On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawsonalaw...@aqorn.com wrote: I think it's easy to quantify a code contributor since we have systems that monitor activity - who contributed, what they contributed and when. But we don't have a system that monitors operator activity and honestly, that's the question mark for which I really don't have any answers. That might be our first hurdle - how define the difference between a causal user making remarks on the mailing lists and someone who works with the technology and engages. We'd have to quantify them differently somehow. Maybe attending an operators meeting would qualify someone to vote? On Apr 30, 2015 5:35 PM, Stefano Maffullistef...@openstack.org wrote: On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Excerpts from Adam Lawson's message of 2015-05-01 09:06:20 -0700: So this is an interesting idea. Would we require operators co-author/review all patches that land? if not (and that actually strikes me as making uploading patches more difficult unnecessarily), My question is how Operators can easily get involved with that process. *Requiring* reviews would be onerous, but we definitely *encourage* them. If Operators want to get recognized for contributing and participate with TC elections, an easy way to start an engagement with some means of tracking would be immensely helpful I think. I think folks who are truly engaged with the existing contributor team will be recognized, and if they feel they are engaged but are not being recognized they should talk to the PTL of the project to understand why. It's likely that not all PTLs are thinking about adding ATCs to their project, and some may just need to be nudged. On the other hand, if you want to have a real, immediate, impact on the future direction of OpenStack start with the folks making the plans for upcoming work by reviewing their proposals. One benefit of the specs review process is that it is open for everyone to participate, and we especially want to hear from operators. I have several times pointed my local meetup group or some individual operators to specifications where I thought their input would be valuable. I don't know how much feedback we're seeing overall from anyone not already designated a contributor (if someone familiar enough with the tools to generate those stats could do it I think it would be useful information). Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
So this is an interesting idea. Would we require operators co-author/review all patches that land? if not (and that actually strikes me as making uploading patches more difficult unnecessarily), My question is how Operators can easily get involved with that process. If Operators want to get recognized for contributing and participate with TC elections, an easy way to start an engagement with some means of tracking would be immensely helpful I think. Does the current system allow this kind of co-authoring/operator review sort of thing? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Fri, May 1, 2015 at 8:44 AM, Joshua Harlow harlo...@outlook.com wrote: Davanum Srinivas wrote: One concrete suggestion based on my experience working with Kris Lindgren on Heartbeat patch: http://markmail.org/message/gifrt5f3mslco24j I could have added a Co-Tested-By (or Co-Operator - get it? :) in my commit message which would have signaled a concrete contribution/feedback with specific folks in the operator community. This could be done not just for code, could be for reviews or documentation etc as well. WDYT? +1 Kris is a great example, and I can think of other operators that should be some sort of ATC (but may not contribute code to get this). IMHO any operator running openstack (let's say at least at 50+ compute nodes) and operating it should get full access to the summit, because their words of advice/experience are just as useful as technical contributors... thanks, dims On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawsonalaw...@aqorn.com wrote: I think it's easy to quantify a code contributor since we have systems that monitor activity - who contributed, what they contributed and when. But we don't have a system that monitors operator activity and honestly, that's the question mark for which I really don't have any answers. That might be our first hurdle - how define the difference between a causal user making remarks on the mailing lists and someone who works with the technology and engages. We'd have to quantify them differently somehow. Maybe attending an operators meeting would qualify someone to vote? On Apr 30, 2015 5:35 PM, Stefano Maffullistef...@openstack.org wrote: On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On Friday, May 1, 2015, Russell Bryant rbry...@redhat.com wrote: On 05/01/2015 02:22 PM, Tim Bell wrote: The spec review process has made it much easier for operators to see what is being proposed and give input. Recognition is a different topic. It also comes into who would be the operator/user electorate ? ATC is simple to define where the equivalent operator/user definition is less clear. I think spec review participation is a great example of where it would make sense to grant extra ATC status. If someone provides valuable spec input, but hasn't made any commits that get ATC status, I'd vote to approve their ATC status if proposed. This is exactly the case for David Chadwick (U of Kent) if anyone is looking for prior examples of someone who has contributed to the spec process but has not landed code and has received ATC for the contributions. This is a great way to confer ATC for spec participation. --Morgan -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
The spec review process has made it much easier for operators to see what is being proposed and give input. Recognition is a different topic. It also comes into who would be the operator/user electorate ? ATC is simple to define where the equivalent operator/user definition is less clear. I’m trying to capture the various comments from this discussion as time permits in the ether pad for the user committee design session at https://etherpad.openstack.org/p/YVR-ops-user-committee but feel free to add further items you’d like to discuss. The user committee or operators mailing list is, IMHO, a better place for these discussions since they are generally paid to run their clouds. Tim (trying to keep up while running a 140K core cloud and doing lots outreach ) From: Adam Lawson alaw...@aqorn.commailto:alaw...@aqorn.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, May 1, 2015 at 6:06 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates So this is an interesting idea. Would we require operators co-author/review all patches that land? if not (and that actually strikes me as making uploading patches more difficult unnecessarily), My question is how Operators can easily get involved with that process. If Operators want to get recognized for contributing and participate with TC elections, an easy way to start an engagement with some means of tracking would be immensely helpful I think. Does the current system allow this kind of co-authoring/operator review sort of thing? Adam Lawson AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 [http://www.aqorn.com/images/logo.png] On Fri, May 1, 2015 at 8:44 AM, Joshua Harlow harlo...@outlook.commailto:harlo...@outlook.com wrote: Davanum Srinivas wrote: One concrete suggestion based on my experience working with Kris Lindgren on Heartbeat patch: http://markmail.org/message/gifrt5f3mslco24j I could have added a Co-Tested-By (or Co-Operator - get it? :) in my commit message which would have signaled a concrete contribution/feedback with specific folks in the operator community. This could be done not just for code, could be for reviews or documentation etc as well. WDYT? +1 Kris is a great example, and I can think of other operators that should be some sort of ATC (but may not contribute code to get this). IMHO any operator running openstack (let's say at least at 50+ compute nodes) and operating it should get full access to the summit, because their words of advice/experience are just as useful as technical contributors... thanks, dims On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawsonalaw...@aqorn.commailto:alaw...@aqorn.com wrote: I think it's easy to quantify a code contributor since we have systems that monitor activity - who contributed, what they contributed and when. But we don't have a system that monitors operator activity and honestly, that's the question mark for which I really don't have any answers. That might be our first hurdle - how define the difference between a causal user making remarks on the mailing lists and someone who works with the technology and engages. We'd have to quantify them differently somehow. Maybe attending an operators meeting would qualify someone to vote? On Apr 30, 2015 5:35 PM, Stefano Maffullistef...@openstack.orgmailto:stef...@openstack.org wrote: On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/01/2015 02:22 PM, Tim Bell wrote: The spec review process has made it much easier for operators to see what is being proposed and give input. Recognition is a different topic. It also comes into who would be the operator/user electorate ? ATC is simple to define where the equivalent operator/user definition is less clear. I think spec review participation is a great example of where it would make sense to grant extra ATC status. If someone provides valuable spec input, but hasn't made any commits that get ATC status, I'd vote to approve their ATC status if proposed. -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
I purposely didn't email the general mailing list since I didn't want to cross-post, hard to have these discussions across verticals and choosing one list = hearing one community - those subscribed to the developer mailing list. So I'm not assuming anything, it seems some are suggesting that Operators get into code review to quantify their role as an engaged Operator. Is that a correct statement? Just want to make sure I'm hearing correctly. I try to avoid absolutes but personally speaking for the record, I don't believe the answer lies with asking Operators to become code reviewers on top of everthing else they're doing in order for them to have a voice in the TC elections. If code reviews are being suggested (again, assuming the assumption is correct for the sake of making my point), technical contribution extends far beyond uploading and reviewing code. This alternate means to gain ATC status seems like a potential candidate for those who want to review code but not for those who are day-to-day operators engaging with the community. Is there any meetings planned in Vancouver where users/operators are meeting where we can add an agenda items to gather input? Given this conversation involves the Operator community as well, I went ahead and CC'd them to hopefully capture their specific thoughts/ideas on the subject. Mahalo, Adam *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Fri, May 1, 2015 at 12:22 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote: On Friday, May 1, 2015, Russell Bryant rbry...@redhat.com wrote: On 05/01/2015 02:22 PM, Tim Bell wrote: The spec review process has made it much easier for operators to see what is being proposed and give input. Recognition is a different topic. It also comes into who would be the operator/user electorate ? ATC is simple to define where the equivalent operator/user definition is less clear. I think spec review participation is a great example of where it would make sense to grant extra ATC status. If someone provides valuable spec input, but hasn't made any commits that get ATC status, I'd vote to approve their ATC status if proposed. This is exactly the case for David Chadwick (U of Kent) if anyone is looking for prior examples of someone who has contributed to the spec process but has not landed code and has received ATC for the contributions. This is a great way to confer ATC for spec participation. --Morgan -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 04/30/15 10:15, Thierry Carrez wrote: Doug Hellmann wrote: Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) I'm going to nitpick on terminology a bit. The TC is elected by *technical contributors*, not developers, as described in the charter: http://governance.openstack.org/reference/charter.html#voters-for-tc-seats-atc +1 I think there is a key misconception in this thread that the TC is supposed to represent (or talk about representing) more than just the technical contributors that produce OpenStack. When the OpenStack Foundation was set up, three bodies of governance were established: - the Board of Directors (representing the community as a whole) - the Technical Committee (representing technical contributors) - the User Committee (representing users and ops of OpenStack) The Technical Committee mandate is therefore not to represent the users and Ops of OpenStack in that setup, it's the role of the User committee. If we did include Ops, we would be clearly overstepping our mandate. Thierry, essentially I agree with you. I do think though that the disconnect between Dev Ops is an unhealthy situation. Two separate bodies working in two different ways with two different agendas is actually very much against the current way that most development organizations are aspire towards. The TC charter [1] states. The Technical Committee (“TC”) is tasked with providing the technical leadership for OpenStack as a whole (all official projects, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple projects, forms an ultimate appeals board for technical decisions, and generally has technical oversight over all of OpenStack. IMHO, the spirit of the original question that was raised was - how can all of OpenStack only be those who write the code, and not those that use and operate it on a day to day basis? Rather than asking that Ops should be able to elect the TC, you should probably start discussing how to improve on the User committee election process and visibility. It would be great to understand how exactly this was done, what their charter is and how much influence they have on technical decisions within the larger OpenStack as a whole [2] [1] http://governance.openstack.org/reference/charter.html [2] https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Doug Hellmann wrote: Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) I'm going to nitpick on terminology a bit. The TC is elected by *technical contributors*, not developers, as described in the charter: http://governance.openstack.org/reference/charter.html#voters-for-tc-seats-atc +1 I think there is a key misconception in this thread that the TC is supposed to represent (or talk about representing) more than just the technical contributors that produce OpenStack. When the OpenStack Foundation was set up, three bodies of governance were established: - the Board of Directors (representing the community as a whole) - the Technical Committee (representing technical contributors) - the User Committee (representing users and ops of OpenStack) The Technical Committee mandate is therefore not to represent the users and Ops of OpenStack in that setup, it's the role of the User committee. If we did include Ops, we would be clearly overstepping our mandate. Rather than asking that Ops should be able to elect the TC, you should probably start discussing how to improve on the User committee election process and visibility. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 30/04/15 12:07 +0300, Maish Saidel-Keesing wrote: On 04/30/15 10:15, Thierry Carrez wrote: Doug Hellmann wrote: Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) I'm going to nitpick on terminology a bit. The TC is elected by *technical contributors*, not developers, as described in the charter: http://governance.openstack.org/reference/charter.html#voters-for-tc-seats-atc +1 I think there is a key misconception in this thread that the TC is supposed to represent (or talk about representing) more than just the technical contributors that produce OpenStack. When the OpenStack Foundation was set up, three bodies of governance were established: - the Board of Directors (representing the community as a whole) - the Technical Committee (representing technical contributors) - the User Committee (representing users and ops of OpenStack) The Technical Committee mandate is therefore not to represent the users and Ops of OpenStack in that setup, it's the role of the User committee. If we did include Ops, we would be clearly overstepping our mandate. Thierry, essentially I agree with you. I do think though that the disconnect between Dev Ops is an unhealthy situation. Two separate bodies working in two different ways with two different agendas is actually very much against the current way that most development organizations are aspire towards. The TC charter [1] states. The Technical Committee (“TC”) is tasked with providing the technical leadership for OpenStack as a whole (all official projects, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple projects, forms an ultimate appeals board for technical decisions, and generally has technical oversight over all of OpenStack. IMHO, the spirit of the original question that was raised was - how can all of OpenStack only be those who write the code, and not those that use and operate it on a day to day basis? Are these thoughts based on the current state of OpenStack? or are they influenced a bit by our past? The reason I ask is because I believe we've come a long way on integrating more with Ops and Users. New groups have been created, new meetups have been run, a dedicated day has been assigned at the summit, a dedicated mailing list - that most of us follow - has been created, etc, etc, etc. I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. While I don't consider we're there yet, I do think there have been several improvements in this area, which is why I'm curious to know the answer to my questions above. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. Flavio Rather than asking that Ops should be able to elect the TC, you should probably start discussing how to improve on the User committee election process and visibility. It would be great to understand how exactly this was done, what their charter is and how much influence they have on technical decisions within the larger OpenStack as a whole [2] [1] http://governance.openstack.org/reference/charter.html [2] https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco pgpFnYaEzcDPB.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
For the record, thanks for your replies guys. I am not suggesting any specific means to resolve or suggesting what we're doing is wrong; only that the current structure seems odd. The TC charter, as I read it, states that the TC committee represents everything of a technical nature of OpenStack via this quote: generally has technical oversight over all of OpenStack. That includes whatever the Operators contribute or engage with (all of OpenStack). Given OpenStack has a vibrant Operators community who contribute a great deal in terms of rubber on the road feedback, suggestions for improvement and real-world implementation reality checks, it seems appropriate that the committee tasked to oversee everything technical within OpenStack (which I think we all agree encompasses more than those who contribute code) should not be disallowing one community but allowing another to elect that committee. This i know is totally my opinion, but if we require Operators to seek special approval, that doesn't seem to fit our ideal goals of Commonality. Whatever we need to do to quantify those who contribute to OpenStack versus those who don't is tricky I agree. I don't know the answer. But it would seem to me the current situation is ripe for a change. *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Thu, Apr 30, 2015 at 3:26 AM, Flavio Percoco fla...@redhat.com wrote: On 30/04/15 12:07 +0300, Maish Saidel-Keesing wrote: On 04/30/15 10:15, Thierry Carrez wrote: Doug Hellmann wrote: Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) I'm going to nitpick on terminology a bit. The TC is elected by *technical contributors*, not developers, as described in the charter: http://governance.openstack.org/reference/charter.html#voters-for-tc-seats-atc +1 I think there is a key misconception in this thread that the TC is supposed to represent (or talk about representing) more than just the technical contributors that produce OpenStack. When the OpenStack Foundation was set up, three bodies of governance were established: - the Board of Directors (representing the community as a whole) - the Technical Committee (representing technical contributors) - the User Committee (representing users and ops of OpenStack) The Technical Committee mandate is therefore not to represent the users and Ops of OpenStack in that setup, it's the role of the User committee. If we did include Ops, we would be clearly overstepping our mandate. Thierry, essentially I agree with you. I do think though that the disconnect between Dev Ops is an unhealthy situation. Two separate bodies working in two different ways with two different agendas is actually very much against the current way that most development organizations are aspire towards. The TC charter [1] states. The Technical Committee (“TC”) is tasked with providing the technical leadership for OpenStack as a whole (all official projects, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple projects, forms an ultimate appeals board for technical decisions, and generally has technical oversight over all of OpenStack. IMHO, the spirit of the original question that was raised was - how can all of OpenStack only be those who write the code, and not those that use and operate it on a day to day basis? Are these thoughts based on the current state of OpenStack? or are they influenced a bit by our past? The reason I ask is because I believe we've come a long way on integrating more with Ops and Users. New groups have been created, new meetups have been run, a dedicated day has been assigned at the summit, a dedicated mailing list - that most of us follow - has been created, etc, etc, etc. I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. While I don't consider we're there yet, I do think there have been several improvements in this area, which is why I'm curious to know the answer to my questions above. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
One concrete suggestion based on my experience working with Kris Lindgren on Heartbeat patch: http://markmail.org/message/gifrt5f3mslco24j I could have added a Co-Tested-By (or Co-Operator - get it? :) in my commit message which would have signaled a concrete contribution/feedback with specific folks in the operator community. This could be done not just for code, could be for reviews or documentation etc as well. WDYT? thanks, dims On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawson alaw...@aqorn.com wrote: I think it's easy to quantify a code contributor since we have systems that monitor activity - who contributed, what they contributed and when. But we don't have a system that monitors operator activity and honestly, that's the question mark for which I really don't have any answers. That might be our first hurdle - how define the difference between a causal user making remarks on the mailing lists and someone who works with the technology and engages. We'd have to quantify them differently somehow. Maybe attending an operators meeting would qualify someone to vote? On Apr 30, 2015 5:35 PM, Stefano Maffulli stef...@openstack.org wrote: On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 1 May 2015 at 13:24, Davanum Srinivas dava...@gmail.com wrote: One concrete suggestion based on my experience working with Kris Lindgren on Heartbeat patch: http://markmail.org/message/gifrt5f3mslco24j I could have added a Co-Tested-By (or Co-Operator - get it? :) in my commit message which would have signaled a concrete contribution/feedback with specific folks in the operator community. This could be done not just for code, could be for reviews or documentation etc as well. WDYT? thanks, dims I'd just use Co-Authored-By: - authoring is a rich activity, wider than 'typed into a code editor' - I commonly add Co-Authored-By for folk I've discussed things with during design etc. Arguably code review should get that too, but there's both a chicken-egg thing there, and also you'd want to let the contributor make an assessment as to at what point the 'is a coauthor' threshold has been passed. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
I think it's easy to quantify a code contributor since we have systems that monitor activity - who contributed, what they contributed and when. But we don't have a system that monitors operator activity and honestly, that's the question mark for which I really don't have any answers. That might be our first hurdle - how define the difference between a causal user making remarks on the mailing lists and someone who works with the technology and engages. We'd have to quantify them differently somehow. Maybe attending an operators meeting would qualify someone to vote? On Apr 30, 2015 5:35 PM, Stefano Maffulli stef...@openstack.org wrote: On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On Apr 29, 2015, at 1:34 PM, Adam Lawson alaw...@aqorn.com wrote: Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) I think that the reason may be that historically the people on the TC have come from the dev side of things, and as a result the ops side has been ignored (or not given sufficient attention). Since this is something that we are now all aware of, and since developing OpenStack is kind of worthless if it can't be deployed and run well, this is the area we more or less agree needs improvement. How we might go about improving it is where you may see differences. -- Ed Leafe signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Excerpts from Adam Lawson's message of 2015-04-29 11:34:40 -0700: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) I'm going to nitpick on terminology a bit. The TC is elected by *technical contributors*, not developers, as described in the charter: http://governance.openstack.org/reference/charter.html#voters-for-tc-seats-atc The easy measure of whether someone is an ATC is the first rule listed there: Individual Members who committed a change to a repository under ‘’any’’ of the official OpenStack Project Teams (as defined above) over the last two 6-month release cycles are automatically considered ATC. That's the rule most of us remember, and think of when we think of ATC, but not everyone who does that is a developer and landing a patch is not the only way to become an ATC, as the next sentence shows: Specific contributors who did not have a change recently accepted in one of the OpenStack projects but nevertheless feel their contribution to the OpenStack project is technical in nature (bug triagers, technical documentation writers...) can exceptionally apply for ATC either by sending an email to the TC chair or by being nominated by an existing ATC via email to the TC chair. We have a not-very-long list of folks who have that status in http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs Is it be feasible to start allowing the operator community to also cast votes for TC candidates? Is the TC *only* addressing technical concerns that are relevant to the development community? Since the TC candidates are embracing the idea of representing more than just the developer community, it would /seem/ the voters electing the TC members should include the communities being represented. If the TC only addresses developer concerns, it would seem they become at risk of losing touch with the operator/architecture/user concerns because the operator community voice is never heard in the voting booth. The TC represents the contributors to the project. That term can be defined very broadly, as explained above, but I don't think we want it to be completely open-ended because the issues the TC tries to resolve *are* from the contributors' perspectives, and not every user or deployer's perspective. That's not to say those groups don't have valid concerns, or that the TC would ignore them, just that the TC is not specifically organized to represent them. I would rather we explore more ways to identify people we consider to be contributors than to change the existing voting rules to allow more people. I think it will amount to the same change in the electorate, and I like the idea of adding more contributors to the project more than just adding more voters. :-) Doug Perhaps this bumps into how it used to be versus how it should be. I don't know. Just struck me as incongruent with the platform of almost every candidate - broadening representation while the current rules prohibit that level of co-participation. Thoughts? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
