[all][tc][uc] Uniting the TC and the UC
Hi all,
When our current project governance was established in 2012, we defined two separate bodies. The Technical Committee represented developers / code contributors to the open source project(s), while the User Committee represented the operators running the resulting software, as well as users of the APIs.
That setup served us well in those early days. The focus on the upstream side was strongly around *development* of code, we did not have that many users, and even less users directly involved in upstream development. A separate User Committee resulted in the formation of an engaged community of users, and ensured that our community in general (and our events in particular) took the needs of operators into account.
Fast-forward to 2020: the upstream focus is more on maintenance. We now have a lot of users, and thanks to the efforts of the UC they are increasingly directly involved in the open source project development, with several operators leading upstream project teams directly. There is now limited UC-specific activity, and as such it is struggling to get volunteers to step up for it: nobody nominated themselves for the last round of election.
Keeping two separate bodies to represent them maintains the illusion that devs and ops are different breeds, and sometimes discourages operators from running for the TC and more directly influence the shape of the software. If anything, we need more ops representation at the TC, and seeing people like mnaser being elected at (and chairing) the TC was a great experience. I discussed the situation with the current UC members, and we decided it's time to consider having a single "community" and a single body to represent it.
That body would tackle the traditional TC tasks (open source project governance and stewardship) but also the UC tasks (user survey, ambassador program...). That body would be elected by contributors, in a large sense that includes the AUC definition. I feel like that would help remove the artificial barriers discouraging users to get more directly involved with software development and maintenance.
There are multiple ways to achieve that, in increasing order of complexity and bylaws changes needed:
1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together.
2- Minimal bylaws change Same, but all mentions of the UC would be removed from the bylaws (affecting sections 4.12, 4.14, and Appendix 10). This would require a simple vote by the Board of Directors, and would avoid some confusion and having to formally designate a subset of the TC to respect the letter of the bylaws.
3- Maximal bylaws change Create a new body ("steering committee" for example) replacing the TC and the UC. This would require changing sections 4.1, 4.12, 4.13, 4.14, 4.20, 7.1.b, 7.4, 9.1, 9.2.d, and Appendixes 4 and 10. Section 4.13, 7.1 and 7.4 being heavily protected in the bylaws, they require special votes by each class of Foundation members, probably a multi-year effort. A lot of documentation would also need to be changed in case the TC is renamed.
I personally don't think the benefit of the change offsets the large cost of option (3). Given the current vacancy in the UC makeup I would recommend we pursue option 1 immediately (starting at the next TC election in April), and propose minimal bylaws change to the board in parallel (option 2).
Thoughts ?
On Tue, Feb 25, 2020 at 11:27 AM Thierry Carrez thierry@openstack.org wrote:
Hi all,
When our current project governance was established in 2012, we defined two separate bodies. The Technical Committee represented developers / code contributors to the open source project(s), while the User Committee represented the operators running the resulting software, as well as users of the APIs.
That setup served us well in those early days. The focus on the upstream side was strongly around *development* of code, we did not have that many users, and even less users directly involved in upstream development. A separate User Committee resulted in the formation of an engaged community of users, and ensured that our community in general (and our events in particular) took the needs of operators into account.
Fast-forward to 2020: the upstream focus is more on maintenance. We now have a lot of users, and thanks to the efforts of the UC they are increasingly directly involved in the open source project development, with several operators leading upstream project teams directly. There is now limited UC-specific activity, and as such it is struggling to get volunteers to step up for it: nobody nominated themselves for the last round of election.
Keeping two separate bodies to represent them maintains the illusion that devs and ops are different breeds, and sometimes discourages operators from running for the TC and more directly influence the shape of the software. If anything, we need more ops representation at the TC, and seeing people like mnaser being elected at (and chairing) the TC was a great experience. I discussed the situation with the current UC members, and we decided it's time to consider having a single "community" and a single body to represent it.
That body would tackle the traditional TC tasks (open source project governance and stewardship) but also the UC tasks (user survey, ambassador program...). That body would be elected by contributors, in a large sense that includes the AUC definition. I feel like that would help remove the artificial barriers discouraging users to get more directly involved with software development and maintenance.
There are multiple ways to achieve that, in increasing order of complexity and bylaws changes needed:
1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together.
2- Minimal bylaws change Same, but all mentions of the UC would be removed from the bylaws (affecting sections 4.12, 4.14, and Appendix 10). This would require a simple vote by the Board of Directors, and would avoid some confusion and having to formally designate a subset of the TC to respect the letter of the bylaws.
3- Maximal bylaws change Create a new body ("steering committee" for example) replacing the TC and the UC. This would require changing sections 4.1, 4.12, 4.13, 4.14, 4.20, 7.1.b, 7.4, 9.1, 9.2.d, and Appendixes 4 and 10. Section 4.13, 7.1 and 7.4 being heavily protected in the bylaws, they require special votes by each class of Foundation members, probably a multi-year effort. A lot of documentation would also need to be changed in case the TC is renamed.
I personally don't think the benefit of the change offsets the large cost of option (3). Given the current vacancy in the UC makeup I would recommend we pursue option 1 immediately (starting at the next TC election in April), and propose minimal bylaws change to the board in parallel (option 2).
I personally agree with this option as that seems like the best possible option moving forwards.
Thoughts ?
-- Thierry Carrez
---- On Tue, 25 Feb 2020 04:23:56 -0600 Thierry Carrez thierry@openstack.org wrote ----
Hi all,
When our current project governance was established in 2012, we defined two separate bodies. The Technical Committee represented developers / code contributors to the open source project(s), while the User Committee represented the operators running the resulting software, as well as users of the APIs.
That setup served us well in those early days. The focus on the upstream side was strongly around *development* of code, we did not have that many users, and even less users directly involved in upstream development. A separate User Committee resulted in the formation of an engaged community of users, and ensured that our community in general (and our events in particular) took the needs of operators into account.
Fast-forward to 2020: the upstream focus is more on maintenance. We now have a lot of users, and thanks to the efforts of the UC they are increasingly directly involved in the open source project development, with several operators leading upstream project teams directly. There is now limited UC-specific activity, and as such it is struggling to get volunteers to step up for it: nobody nominated themselves for the last round of election.
Keeping two separate bodies to represent them maintains the illusion that devs and ops are different breeds, and sometimes discourages operators from running for the TC and more directly influence the shape of the software. If anything, we need more ops representation at the TC, and seeing people like mnaser being elected at (and chairing) the TC was a great experience. I discussed the situation with the current UC members, and we decided it's time to consider having a single "community" and a single body to represent it.
That body would tackle the traditional TC tasks (open source project governance and stewardship) but also the UC tasks (user survey, ambassador program...). That body would be elected by contributors, in a large sense that includes the AUC definition. I feel like that would help remove the artificial barriers discouraging users to get more directly involved with software development and maintenance.
There are multiple ways to achieve that, in increasing order of complexity and bylaws changes needed:
1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together.
Thanks a lot, ttx for starting this thread.
option 1 looks more feasible way but few question/feedback: - How we will execute the "designate 5 members from TC and select UC chair"?
If by volunteer call from TC? I think this can lead to the current situation where very few members are interested to serve as UC. I am afraid that we will get 5 volunteers and a chair.
If by force? I do not think this is or should be an option :). But if then how we make sure the TC members are ok/good to handle the UC tasks on the non-technical side for example ambassador program.
- Will there be any change in TC elections, votes weightage and nomination? by this change of a new subteam under TC?
- I think along with the merging proposal, we should distribute the current tasks handled by UC among TC, Ops group, foundation etc. For example, the ambassador program, local user group interaction or any other managerial tasks should be excluded from TC scope. If we would like to merge all then I think we should rename TC to Steering Committee or something which is option 3.
- What about merging UC into Ops team, they are more close to users/operators and active in terms of the meetup and providing feedback etc.
-gmann
2- Minimal bylaws change Same, but all mentions of the UC would be removed from the bylaws (affecting sections 4.12, 4.14, and Appendix 10). This would require a simple vote by the Board of Directors, and would avoid some confusion and having to formally designate a subset of the TC to respect the letter of the bylaws.
3- Maximal bylaws change Create a new body ("steering committee" for example) replacing the TC and the UC. This would require changing sections 4.1, 4.12, 4.13, 4.14, 4.20, 7.1.b, 7.4, 9.1, 9.2.d, and Appendixes 4 and 10. Section 4.13, 7.1 and 7.4 being heavily protected in the bylaws, they require special votes by each class of Foundation members, probably a multi-year effort. A lot of documentation would also need to be changed in case the TC is renamed.
I personally don't think the benefit of the change offsets the large cost of option (3). Given the current vacancy in the UC makeup I would recommend we pursue option 1 immediately (starting at the next TC election in April), and propose minimal bylaws change to the board in parallel (option 2).
Thoughts ?
-- Thierry Carrez
Option 1 is definitely the fastest though I do wish we could have a more unified name for the group. It's not just a UC issue of not having enough people to run, the last TC election I believe did not have an actual vote after nominations.
Either we have a unified group that oversees the direction of the community or keep them separate as they are now.
OPS Meetup reports to the UC in a sense and is not a totally different group.
Amy (spotz)
On Tue, Feb 25, 2020 at 9:23 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Tue, 25 Feb 2020 04:23:56 -0600 Thierry Carrez < thierry@openstack.org> wrote ----
Hi all,
When our current project governance was established in 2012, we defined two separate bodies. The Technical Committee represented developers / code contributors to the open source project(s), while the User Committee represented the operators running the resulting software, as well as users of the APIs.
That setup served us well in those early days. The focus on the
upstream
side was strongly around *development* of code, we did not have that many users, and even less users directly involved in upstream development. A separate User Committee resulted in the formation of an engaged community of users, and ensured that our community in general (and our events in particular) took the needs of operators into account.
Fast-forward to 2020: the upstream focus is more on maintenance. We now have a lot of users, and thanks to the efforts of the UC they are increasingly directly involved in the open source project development, with several operators leading upstream project teams directly. There
is
now limited UC-specific activity, and as such it is struggling to get volunteers to step up for it: nobody nominated themselves for the last round of election.
Keeping two separate bodies to represent them maintains the illusion that devs and ops are different breeds, and sometimes discourages operators from running for the TC and more directly influence the shape of the software. If anything, we need more ops representation at the
TC,
and seeing people like mnaser being elected at (and chairing) the TC
was
a great experience. I discussed the situation with the current UC members, and we decided it's time to consider having a single "community" and a single body to represent it.
That body would tackle the traditional TC tasks (open source project governance and stewardship) but also the UC tasks (user survey, ambassador program...). That body would be elected by contributors, in
a
large sense that includes the AUC definition. I feel like that would help remove the artificial barriers discouraging users to get more directly involved with software development and maintenance.
There are multiple ways to achieve that, in increasing order of complexity and bylaws changes needed:
1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding
all
AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together.
Thanks a lot, ttx for starting this thread.
option 1 looks more feasible way but few question/feedback:
- How we will execute the "designate 5 members from TC and select UC
chair"?
If by volunteer call from TC? I think this can lead to the current situation where very few members are interested to serve as UC. I am afraid that we will get 5 volunteers and a chair.
If by force? I do not think this is or should be an option :). But if then how we make sure the TC members are ok/good to handle the UC tasks on the non-technical side for example ambassador program.
- Will there be any change in TC elections, votes weightage and
nomination? by this change of a new subteam under TC?
- I think along with the merging proposal, we should distribute the
current tasks handled by UC among TC, Ops group, foundation etc. For example, the ambassador program, local user group interaction or any other managerial tasks should be excluded from TC scope. If we would like to merge all then I think we should rename TC to Steering Committee or something which is option 3.
- What about merging UC into Ops team, they are more close to
users/operators and active in terms of the meetup and providing feedback etc.
-gmann
2- Minimal bylaws change Same, but all mentions of the UC would be removed from the bylaws (affecting sections 4.12, 4.14, and Appendix 10). This would require a simple vote by the Board of Directors, and would avoid some confusion and having to formally designate a subset of the TC to respect the letter of the bylaws.
3- Maximal bylaws change Create a new body ("steering committee" for example) replacing the TC and the UC. This would require changing sections 4.1, 4.12, 4.13, 4.14, 4.20, 7.1.b, 7.4, 9.1, 9.2.d, and Appendixes 4 and 10. Section 4.13,
7.1
and 7.4 being heavily protected in the bylaws, they require special votes by each class of Foundation members, probably a multi-year
effort.
A lot of documentation would also need to be changed in case the TC is renamed.
I personally don't think the benefit of the change offsets the large cost of option (3). Given the current vacancy in the UC makeup I would recommend we pursue option 1 immediately (starting at the next TC election in April), and propose minimal bylaws change to the board in parallel (option 2).
Thoughts ?
-- Thierry Carrez
Are there some stats on the active electorate sizes ?
I have the impression that the voting AUCs were a smaller number of people than the contributors so a single election may result in less total representation compared to today’s UC & TC.
Tim
On 25 Feb 2020, at 17:00, Amy Marrich <amy@demarco.commailto:amy@demarco.com> wrote:
Option 1 is definitely the fastest though I do wish we could have a more unified name for the group. It's not just a UC issue of not having enough people to run, the last TC election I believe did not have an actual vote after nominations.
Either we have a unified group that oversees the direction of the community or keep them separate as they are now.
OPS Meetup reports to the UC in a sense and is not a totally different group.
Amy (spotz)
On Tue, Feb 25, 2020 at 9:23 AM Ghanshyam Mann <gmann@ghanshyammann.commailto:gmann@ghanshyammann.com> wrote: ---- On Tue, 25 Feb 2020 04:23:56 -0600 Thierry Carrez <thierry@openstack.orgmailto:thierry@openstack.org> wrote ----
Hi all,
When our current project governance was established in 2012, we defined two separate bodies. The Technical Committee represented developers / code contributors to the open source project(s), while the User Committee represented the operators running the resulting software, as well as users of the APIs.
That setup served us well in those early days. The focus on the upstream side was strongly around *development* of code, we did not have that many users, and even less users directly involved in upstream development. A separate User Committee resulted in the formation of an engaged community of users, and ensured that our community in general (and our events in particular) took the needs of operators into account.
Fast-forward to 2020: the upstream focus is more on maintenance. We now have a lot of users, and thanks to the efforts of the UC they are increasingly directly involved in the open source project development, with several operators leading upstream project teams directly. There is now limited UC-specific activity, and as such it is struggling to get volunteers to step up for it: nobody nominated themselves for the last round of election.
Keeping two separate bodies to represent them maintains the illusion that devs and ops are different breeds, and sometimes discourages operators from running for the TC and more directly influence the shape of the software. If anything, we need more ops representation at the TC, and seeing people like mnaser being elected at (and chairing) the TC was a great experience. I discussed the situation with the current UC members, and we decided it's time to consider having a single "community" and a single body to represent it.
That body would tackle the traditional TC tasks (open source project governance and stewardship) but also the UC tasks (user survey, ambassador program...). That body would be elected by contributors, in a large sense that includes the AUC definition. I feel like that would help remove the artificial barriers discouraging users to get more directly involved with software development and maintenance.
There are multiple ways to achieve that, in increasing order of complexity and bylaws changes needed:
1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together.
Thanks a lot, ttx for starting this thread.
option 1 looks more feasible way but few question/feedback: - How we will execute the "designate 5 members from TC and select UC chair"?
If by volunteer call from TC? I think this can lead to the current situation where very few members are interested to serve as UC. I am afraid that we will get 5 volunteers and a chair.
If by force? I do not think this is or should be an option :). But if then how we make sure the TC members are ok/good to handle the UC tasks on the non-technical side for example ambassador program.
- Will there be any change in TC elections, votes weightage and nomination? by this change of a new subteam under TC?
- I think along with the merging proposal, we should distribute the current tasks handled by UC among TC, Ops group, foundation etc. For example, the ambassador program, local user group interaction or any other managerial tasks should be excluded from TC scope. If we would like to merge all then I think we should rename TC to Steering Committee or something which is option 3.
- What about merging UC into Ops team, they are more close to users/operators and active in terms of the meetup and providing feedback etc.
-gmann
2- Minimal bylaws change Same, but all mentions of the UC would be removed from the bylaws (affecting sections 4.12, 4.14, and Appendix 10). This would require a simple vote by the Board of Directors, and would avoid some confusion and having to formally designate a subset of the TC to respect the letter of the bylaws.
3- Maximal bylaws change Create a new body ("steering committee" for example) replacing the TC and the UC. This would require changing sections 4.1, 4.12, 4.13, 4.14, 4.20, 7.1.b, 7.4, 9.1, 9.2.d, and Appendixes 4 and 10. Section 4.13, 7.1 and 7.4 being heavily protected in the bylaws, they require special votes by each class of Foundation members, probably a multi-year effort. A lot of documentation would also need to be changed in case the TC is renamed.
I personally don't think the benefit of the change offsets the large cost of option (3). Given the current vacancy in the UC makeup I would recommend we pursue option 1 immediately (starting at the next TC election in April), and propose minimal bylaws change to the board in parallel (option 2).
Thoughts ?
-- Thierry Carrez
Tim Bell wrote:
Are there some stats on the active electorate sizes ?
I have the impression that the voting AUCs were a smaller number of people than the contributors so a single election may result in less total representation compared to today’s UC & TC.
I don't have the exact numbers around, but yes, there are many more ATCs (voters in the current TC election) than AUCs (voters in the current UC election).
So it's a valid concern that people with more of an operator background would have trouble getting elected if the electorate contains more people with more of a developer background.
But I think it's a fallacy. There is plenty of overlap. Most engaged operators are already ATCs, and more and more contributors have operational experience. Data points show that when people with more operational background have nominated themselves for the TC in recent elections, they got elected. 10 of the 13 TC seats are currently occupied by people with some decent amount of operational experience.
So yes, we clearly need to communicate that people with operational/usage experience are wanted in that new body. We need to communicate that there is a change, and a single body will now steward all aspects of the open source projects and not just the upstream aspects. But I'm not obsessing on the fact that a single election would somehow suppress operator voices...
The problem recently has more been to find enough people willing to step up and spend extra time stewarding OpenStack, than to actually get elected.
Amy Marrich wrote:
Option 1 is definitely the fastest though I do wish we could have a more unified name for the group.
I agree that would have been optimal, to create some rupture and clearly drive the point that Devs+Ops are welcome to the new body.
Unfortunately, there is no way to do that without touching protected sections of the bylaws, at which point the change is just too costly to entertain, compared to the gain...
On 2020-02-25 10:00:14 -0600 (-0600), Amy Marrich wrote: [...]
It's not just a UC issue of not having enough people to run, the last TC election I believe did not have an actual vote after nominations.
[...]
That's a fair point, but there's still a wide gulf between getting just enough (very excellent, by the way) candidates by the scheduled deadline to fill all open seats, and getting none whatsoever. I also knew other folks who were willing to nominate themselves if it got down to the wire and we didn't have enough, but they were confident in the ability of those who had already volunteered so did not feel it necessary. The Technical Committee also took this as a sign that it should work to gradually reduce its size over the course of the next year (thankfully the number of TC seats isn't baked into the OSF bylaws, unlike for the UC).
Ghanshyam Mann wrote:
[...] option 1 looks more feasible way but few question/feedback:
- How we will execute the "designate 5 members from TC and select UC chair"?
If by volunteer call from TC? I think this can lead to the current situation where very few members are interested to serve as UC. I am afraid that we will get 5 volunteers and a chair.
If by force? I do not think this is or should be an option :). But if then how we make sure the TC members are ok/good to handle the UC tasks on the non-technical side for example ambassador program.
The idea here is to satisfy the letter of the bylaws, not to build a subteam.
The bylaws say the UC is a 5-member group, elected following a method they decide on, by an electorate that they define. So one way to not change the bylaws (while having a single election and a single group) is to say that the UC electorate is the elected TC+UC members, have them select 5 people, and address all questions with the whole group.
I suspect we'd choose the people with the most operations experience, but it actually would not matter.
I'd just like to add that I see those 3 points as steps. Indeed doing 1 looks best atm and can be followed by 2 and then 3. They sound incremental.
-yoctozepto
On 25/02/20 5:23 am, Thierry Carrez wrote:
1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together.
I think there's an even simpler approach. Any member of the foundation can nominate themselves as a UC member. In the past we've just kept extending the deadline until someone steps up. So the *simplest* thing to do is:
* Run the election process as usual. If any users want to step up they are welcome to, and on past performance very likely to be acclaimed without an election. * If the deadline passes, the TC commits to finding enough warm bodies who are foundation members to fill any remaining seats, including from among its own members if necessary. * The additional volunteers are acclaimed, and all members of the UC elect a chair. * We accept that to the extent that the UC has duties to perform and ambassadors to help, this will largely remain un-done.
This eliminates the issue of actual users needing to submit themselves to an election of all ATCs + AUCs in order to get a seat (which tbh seems questionable under the bylaws, since not all ATCs are AUCs).
- ZB
That’s not a bad plan Zane, but are you still thinking separate or the unified group?
Amy
On Feb 25, 2020, at 7:42 PM, Zane Bitter zbitter@redhat.com wrote:
On 25/02/20 5:23 am, Thierry Carrez wrote:
1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together.
I think there's an even simpler approach. Any member of the foundation can nominate themselves as a UC member. In the past we've just kept extending the deadline until someone steps up. So the *simplest* thing to do is:
- Run the election process as usual. If any users want to step up they are welcome to, and on past performance very likely to be acclaimed without an election.
- If the deadline passes, the TC commits to finding enough warm bodies who are foundation members to fill any remaining seats, including from among its own members if necessary.
- The additional volunteers are acclaimed, and all members of the UC elect a chair.
- We accept that to the extent that the UC has duties to perform and ambassadors to help, this will largely remain un-done.
This eliminates the issue of actual users needing to submit themselves to an election of all ATCs + AUCs in order to get a seat (which tbh seems questionable under the bylaws, since not all ATCs are AUCs).
- ZB
---- On Tue, 25 Feb 2020 19:39:36 -0600 Zane Bitter zbitter@redhat.com wrote ----
On 25/02/20 5:23 am, Thierry Carrez wrote:
1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together.
I think there's an even simpler approach. Any member of the foundation can nominate themselves as a UC member. In the past we've just kept extending the deadline until someone steps up. So the *simplest* thing to do is:
- Run the election process as usual. If any users want to step up they
are welcome to, and on past performance very likely to be acclaimed without an election.
- If the deadline passes, the TC commits to finding enough warm bodies
who are foundation members to fill any remaining seats, including from among its own members if necessary.
TC or BoDs ? If TC then we still need Bylaw change to remove the number of UC and mention, TC owns to make UC team even with one or more members. Because the number of 5 UC in Bylaw is something that has to be fixed.
But again the main question is how TC will find the members as nobody even from TC are not running for UC.
-gmann
- The additional volunteers are acclaimed, and all members of the UC
elect a chair.
- We accept that to the extent that the UC has duties to perform and
ambassadors to help, this will largely remain un-done.
This eliminates the issue of actual users needing to submit themselves to an election of all ATCs + AUCs in order to get a seat (which tbh seems questionable under the bylaws, since not all ATCs are AUCs).
- ZB
On 25/02/20 9:29 pm, Ghanshyam Mann wrote:
---- On Tue, 25 Feb 2020 19:39:36 -0600 Zane Bitter zbitter@redhat.com wrote ----
On 25/02/20 5:23 am, Thierry Carrez wrote:
1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together.
I think there's an even simpler approach. Any member of the foundation can nominate themselves as a UC member. In the past we've just kept extending the deadline until someone steps up. So the *simplest* thing to do is:
- Run the election process as usual. If any users want to step up they
are welcome to, and on past performance very likely to be acclaimed without an election.
- If the deadline passes, the TC commits to finding enough warm bodies
who are foundation members to fill any remaining seats, including from among its own members if necessary.
TC or BoDs ?
The TC, but there's no formal role here. TC members just commit amongst themselves to doing whatever it takes to make sure the requisite number of volunteers appear, up to and including volunteering themselves if necessary.
If TC then we still need Bylaw change to remove the number of UC and mention, TC owns to make UC team even with one or more members. Because the number of 5 UC in Bylaw is something that has to be fixed.
No, what I'm saying is that the TC will ensure the UC always has exactly 5 members so the bylaws can remain unchanged.
But again the main question is how TC will find the members as nobody even from TC are not running for UC.
Easy, like this:
Dear <insert name here>, Congratulations, you just volunteered to be a UC member! But don't worry, because there are no duties other than showing up for roll call twice a year.
love, the TC
-gmann
- The additional volunteers are acclaimed, and all members of the UC
elect a chair.
- We accept that to the extent that the UC has duties to perform and
ambassadors to help, this will largely remain un-done.
This eliminates the issue of actual users needing to submit themselves to an election of all ATCs + AUCs in order to get a seat (which tbh seems questionable under the bylaws, since not all ATCs are AUCs).
- ZB
---- On Wed, 26 Feb 2020 10:21:45 -0600 Zane Bitter zbitter@redhat.com wrote ----
On 25/02/20 9:29 pm, Ghanshyam Mann wrote:
---- On Tue, 25 Feb 2020 19:39:36 -0600 Zane Bitter zbitter@redhat.com wrote ----
On 25/02/20 5:23 am, Thierry Carrez wrote:
1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together.
I think there's an even simpler approach. Any member of the foundation can nominate themselves as a UC member. In the past we've just kept extending the deadline until someone steps up. So the *simplest* thing to do is:
- Run the election process as usual. If any users want to step up they
are welcome to, and on past performance very likely to be acclaimed without an election.
- If the deadline passes, the TC commits to finding enough warm bodies
who are foundation members to fill any remaining seats, including from among its own members if necessary.
TC or BoDs ?
The TC, but there's no formal role here. TC members just commit amongst themselves to doing whatever it takes to make sure the requisite number of volunteers appear, up to and including volunteering themselves if necessary.
If TC then we still need Bylaw change to remove the number of UC and mention, TC owns to make UC team even with one or more members. Because the number of 5 UC in Bylaw is something that has to be fixed.
No, what I'm saying is that the TC will ensure the UC always has exactly 5 members so the bylaws can remain unchanged.
But again the main question is how TC will find the members as nobody even from TC are not running for UC.
Easy, like this:
Dear <insert name here>, Congratulations, you just volunteered to be a UC member! But don't worry, because there are no duties other than showing up for roll call twice a year.
:) 'no duties'. Then it makes sense to update the Bylaw to remove UC reference from it and have single governance as TC.
Because keeping a team with no duties is negative impression and I will say either we have team working on its mission/duties as a separate team or merged into TC with relevant duties or if those duties are ok not to be done then it is clear that nobody depends on those duties or someone else is doing it indirectly so closing the team is the right approach.
-gmann
love, the TC
-gmann
- The additional volunteers are acclaimed, and all members of the UC
elect a chair.
- We accept that to the extent that the UC has duties to perform and
ambassadors to help, this will largely remain un-done.
This eliminates the issue of actual users needing to submit themselves to an election of all ATCs + AUCs in order to get a seat (which tbh seems questionable under the bylaws, since not all ATCs are AUCs).
- ZB
On 2020-02-26 11:13:41 -0600 (-0600), Ghanshyam Mann wrote: [...]
:) 'no duties'. Then it makes sense to update the Bylaw to remove UC reference from it and have single governance as TC.
Because keeping a team with no duties is negative impression and I will say either we have team working on its mission/duties as a separate team or merged into TC with relevant duties or if those duties are ok not to be done then it is clear that nobody depends on those duties or someone else is doing it indirectly so closing the team is the right approach.
Even if it makes sense for the long term, that still leaves the question as to what to do in the meantime, for the years it will take to get those changes to the bylaws enacted.
On 2020-02-25 20:39:36 -0500 (-0500), Zane Bitter wrote: [...]
This eliminates the issue of actual users needing to submit themselves to an election of all ATCs + AUCs in order to get a seat (which tbh seems questionable under the bylaws, since not all ATCs are AUCs).
The OSF bylaws don't define what an AUC is at all, they leave it up to the UC to define their electorate. They do, however, (via the less-protected TC Member Policy appendix) define ATCs but, also declare that the TC can add anyone they like on top of that base definition. This means that the UC can declare their electorate is TC members, or the combined set of current ATCs and AUCs, or whatever, and that the TC can declare all current AUCs are also ATCs if they so choose.
participants (8)
-
Amy Marrich
-
Ghanshyam Mann
-
Jeremy Stanley
-
Mohammed Naser
-
Radosław Piliszek
-
Thierry Carrez
-
Tim Bell
-
Zane Bitter