TSC election suggestions
|
Arnaud Le Hors
Just to be clear,
several of the points listed in that email have already been addressed.
The only two issues left are:
TSC Election voters selection TSC Election observers -- Arnaud Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM From: "Brian Behlendorf" <bbehlendorf@...> To: "'hyperledger-tsc@...'" <hyperledger-tsc@...> Date: 02/06/2020 07:19 PM Subject: [EXTERNAL] [Hyperledger TSC] TSC election suggestions Sent by: tsc@... Hi all. Given conversations this morning on the TSC call, I wanted to bump this thread again, see below. Lots of good conversations here. Let's just close up these open issues so that the election later this year can be smooth. Thanks, https://wiki.hyperledger.org/display/TSC/TSC+Election+voters+selection Brian -------- Forwarded Message --------
Hi all, The HL staff involved in administering the recent TSC election recently met to discuss things we might want to do differently next year, as well as some suggestions we'd have for the TSC, to make next year's election even smoother. 1) It's clear there were some members of the community who felt underinformed about the election timeline and process. The Hyperledger Charter, section 4.II.a, says "The TSC shall approve the process and timing for nominations and elections held on an annual basis." We had created the 2019 Election wiki page and published a timeline there, and announced it on TSC calls, but could have done a better job in ensuring TSC acceptance and buy-in of the process and communication around it. Next time, we suggest that the process & timeline be proposed by the HL staff to the TSC and affirmed by a vote, so that the TSC can ensure and represent to the wider community how it's happening and why it's trustworthy. 2) Along with getting TSC formal approval, it would be helpful to have two or three volunteer election observerswho are not running for the TSC, with whom we can CC on every election-related conversation we have or action we take, who can help us with the voter list, and with whom we can share the results from Condorcet. Apache has election monitors for this purpose. Those monitors, of course, will not have access to the raw votes, just as HL staff do not. 3) Perhaps the biggest source of public confusion, and the greatest amount of work for HL staff, was in creating the list of eligible voters from the myriad of different systems for collaboration, and then de-duping and correcting for invalid addresses. The charter describes an eligible voter very loosely: "anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase". It doesn't tightly define "codebase" nor does it say how much of a contribution is merited, so a one-line edit to the wiki or reporting a bug would qualify. We are happy to see the TSC looking at redefining who's allowed to vote. In Apache, only actual members of the ASF can vote on their board, and there is always a known good email address for reaching someone, and that persists even when individuals change jobs/employers. In addition to other criteria like "easy to describe" and "perceived as fair and hard to game", we would also ask that "easily resolvable to a working email address" be a part of the decision on who's eligible to vote. Any substantive change to eligibility requirements should also be turned into a proposed amendment to the Charter. 4) Regarding nominations: we recommend moving back to public nominations posted to the TSC list, backed with wiki page from the nominee, rather than collecting by form then posting to the wiki at the start of the election. We also recommend doing away with formally nominating someone else to vote. There were three candidates nominated by others who withdrew their candidacy as they weren't aware they were being nominated. And we provided no window between the time we took nominations and the start of the election to verify. 5) Timing. There were some aspects of the election with tight turn-around times during a month, August, when many people are on vacations or otherwise distracted. It may be better to push TSC elections out a month or two; perhaps, use September to do the data collection to determine who's allowed to vote and take nominations, and then October to conduct the vote over a slightly longer period, to maximize potential participation. Hope this is helpful, Brian -- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf |
||||||||
|
|
||||||||
|
Brian Behlendorf
Hi all. Given conversations this morning on the TSC call, I wanted to bump this thread again, see below. Lots of good conversations here. Let's just close up these open issues so that the election later this year can be smooth. Thanks, https://wiki.hyperledger.org/display/TSC/TSC+Election+voters+selectionBrian
-------- Forwarded Message --------
Hi all, The HL staff involved in administering the recent TSC election
recently met to discuss things we might want to do differently
next year, as well as some suggestions we'd have for the TSC, to
make next year's election even smoother. 1) It's clear there were some members of the community who felt underinformed about the election timeline and process. The Hyperledger Charter, section 4.II.a, says "The TSC shall approve the process and timing for nominations and elections held on an annual basis." We had created the 2019 Election wiki page and published a timeline there, and announced it on TSC calls, but could have done a better job in ensuring TSC acceptance and buy-in of the process and communication around it. Next time, we suggest that the process & timeline be proposed by the HL staff to the TSC and affirmed by a vote, so that the TSC can ensure and represent to the wider community how it's happening and why it's trustworthy. 2) Along with getting TSC formal approval, it would be helpful
to have two or three volunteer election observers who
are not running for the TSC, with whom we can CC on every
election-related conversation we have or action we take, who can
help us with the voter list, and with whom we can share the
results from Condorcet. Apache has election monitors for this
purpose. Those monitors, of course, will not have access to the
raw votes, just as HL staff do not. 3) Perhaps the biggest source of public confusion, and the
greatest amount of work for HL staff, was in creating the list
of eligible voters from the myriad of different systems for
collaboration, and then de-duping and correcting for invalid
addresses. The charter describes an eligible voter very
loosely: "anyone in the technical community that contributes
code, documentation or other technical artifacts to the HLP
codebase". It doesn't tightly define "codebase" nor does it say
how much of a contribution is merited, so a one-line edit to the
wiki or reporting a bug would qualify. We are happy to see the
TSC looking at redefining who's allowed to vote. In
Apache, only actual members of the ASF can vote on their board,
and there is always a known good email address for reaching
someone, and that persists even when individuals change
jobs/employers. In addition to other criteria like "easy to
describe" and "perceived as fair and hard to game", we would
also ask that "easily resolvable to a working email address"
be a part of the decision on who's eligible to vote. Any
substantive change to eligibility requirements should also be
turned into a proposed amendment to the Charter. 4) Regarding nominations: we recommend moving back to public nominations posted to the TSC list, backed with wiki page from the nominee, rather than collecting by form then posting to the wiki at the start of the election. We also recommend doing away with formally nominating someone else to vote. There were three candidates nominated by others who withdrew their candidacy as they weren't aware they were being nominated. And we provided no window between the time we took nominations and the start of the election to verify. 5) Timing. There were some aspects of the election with tight turn-around times during a month, August, when many people are on vacations or otherwise distracted. It may be better to push TSC elections out a month or two; perhaps, use September to do the data collection to determine who's allowed to vote and take nominations, and then October to conduct the vote over a slightly longer period, to maximize potential participation. Hope this is helpful, Brian-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf |
||||||||
|
|
||||||||
|
Arnaud Le Hors
I've added a series
of topics to the TSC wiki to capture these proposals and put them on the
agenda for vote:
-- Arnaud Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM From: "Brian Behlendorf" <bbehlendorf@...> To: "tsc@..." <tsc@...> Date: 09/25/2019 08:05 AM Subject: [EXTERNAL] [Hyperledger TSC] TSC election suggestions Sent by: tsc@... Hi all, The HL staff involved in administering the recent TSC election recently met to discuss things we might want to do differently next year, as well as some suggestions we'd have for the TSC, to make next year's election even smoother. 1) It's clear there were some members of the community who felt underinformed about the election timeline and process. The Hyperledger Charter, section 4.II.a, says "The TSC shall approve the process and timing for nominations and elections held on an annual basis." We had created the 2019 Election wiki page and published a timeline there, and announced it on TSC calls, but could have done a better job in ensuring TSC acceptance and buy-in of the process and communication around it. Next time, we suggest that the process & timeline be proposed by the HL staff to the TSC and affirmed by a vote, so that the TSC can ensure and represent to the wider community how it's happening and why it's trustworthy. 2) Along with getting TSC formal approval, it would be helpful to have two or three volunteer election observerswho are not running for the TSC, with whom we can CC on every election-related conversation we have or action we take, who can help us with the voter list, and with whom we can share the results from Condorcet. Apache has election monitors for this purpose. Those monitors, of course, will not have access to the raw votes, just as HL staff do not. 3) Perhaps the biggest source of public confusion, and the greatest amount of work for HL staff, was in creating the list of eligible voters from the myriad of different systems for collaboration, and then de-duping and correcting for invalid addresses. The charter describes an eligible voter very loosely: "anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase". It doesn't tightly define "codebase" nor does it say how much of a contribution is merited, so a one-line edit to the wiki or reporting a bug would qualify. We are happy to see the TSC looking at redefining who's allowed to vote. In Apache, only actual members of the ASF can vote on their board, and there is always a known good email address for reaching someone, and that persists even when individuals change jobs/employers. In addition to other criteria like "easy to describe" and "perceived as fair and hard to game", we would also ask that "easily resolvable to a working email address" be a part of the decision on who's eligible to vote. Any substantive change to eligibility requirements should also be turned into a proposed amendment to the Charter. 4) Regarding nominations: we recommend moving back to public nominations posted to the TSC list, backed with wiki page from the nominee, rather than collecting by form then posting to the wiki at the start of the election. We also recommend doing away with formally nominating someone else to vote. There were three candidates nominated by others who withdrew their candidacy as they weren't aware they were being nominated. And we provided no window between the time we took nominations and the start of the election to verify. 5) Timing. There were some aspects of the election with tight turn-around times during a month, August, when many people are on vacations or otherwise distracted. It may be better to push TSC elections out a month or two; perhaps, use September to do the data collection to determine who's allowed to vote and take nominations, and then October to conduct the vote over a slightly longer period, to maximize potential participation. Hope this is helpful, Brian -- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf |
||||||||
|
|
||||||||
|
+1. I like the idea of a having a longer election moved later and also taking more time to collect the voter list.
Thanks, Swetha |
||||||||
|
|
||||||||
|
Christopher Ferris <chrisfer@...>
I think it also worthwhile to promote the criteria beforehand, and encourage those who may not have contributed recently to do so to ensure that they can get "registered".
Further, I also think that it is useful to remind contributor community what the TSC does and so forth, encouraging them to GOTV.
Cheers,
Christopher Ferris IBM Fellow, CTO Open Technology email: chrisfer@... twitter: @christo4ferris IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/ phone: +1 508 667 0402 ----- Original message ----- |
||||||||
|
|
||||||||
|
hmontgomery@us.fujitsu.com <hmontgomery@...>
+1. This is a great idea. I don’t think it hurts anyone if TSC elections have a longer voting period.
And also +1 to Chris’s idea in the next email of moving the election a little bit later. The current week we have it—the end of August—might be the #1 week of the year for vacations.
Thanks, Hart
From: tsc@... [mailto:tsc@...]
On Behalf Of mark wagner
Sent: Wednesday, September 25, 2019 8:15 AM To: Brian Behlendorf <bbehlendorf@...> Cc: tsc@... Subject: Re: [Hyperledger TSC] TSC election suggestions
Thanks Brian!
Looks great. Regarding the timing and length of the election itself, I think it would be good to make sure that the actual election spans two different calendar weeks to help with vacations, etc.
-mark
On Wed, Sep 25, 2019 at 2:05 AM Brian Behlendorf <bbehlendorf@...> wrote:
Mark Wagner Senior Principal Software Engineer Performance and Scalability Red Hat, Inc |
||||||||
|
|
||||||||
|
Christopher Ferris <chrisfer@...>
and/or move it to September as I had suggested.
Cheers,
Christopher Ferris IBM Fellow, CTO Open Technology email: chrisfer@... twitter: @christo4ferris IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/ phone: +1 508 667 0402 ----- Original message ----- |
||||||||
|
|
||||||||
|
mark wagner <mwagner@...>
Thanks Brian! Looks great. Regarding the timing and length of the election itself, I think it would be good to make sure that the actual election spans two different calendar weeks to help with vacations, etc. -mark On Wed, Sep 25, 2019 at 2:05 AM Brian Behlendorf <bbehlendorf@...> wrote:
-- Mark Wagner Senior Principal Software Engineer |
||||||||
|
|
||||||||
|
Arnaud Le Hors
I agree, this all
sounds good to me.
toggle quoted message
Show quoted text
-- Arnaud Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM From: "greg m" <greg_not_so@...> To: Brian Behlendorf <bbehlendorf@...>, "tsc@..." <tsc@...> Date: 09/25/2019 12:38 PM Subject: [EXTERNAL] Re: [Hyperledger TSC] TSC election suggestions Sent by: tsc@... Brian, It's hard to argue with such excellent ideas. Thank you, greg From: Brian Behlendorf Sent: 9/24/2019 11:05 PM To: tsc@... Subject: [Hyperledger TSC] TSC election suggestions Hi all, The HL staff involved in administering the recent TSC election recently met to discuss things we might want to do differently next year, as well as some suggestions we'd have for the TSC, to make next year's election even smoother. 1) It's clear there were some members of the community who felt underinformed about the election timeline and process. The Hyperledger Charter, section 4.II.a, says "The TSC shall approve the process and timing for nominations and elections held on an annual basis." We had created the 2019 Election wiki page and published a timeline there, and announced it on TSC calls, but could have done a better job in ensuring TSC acceptance and buy-in of the process and communication around it. Next time, we suggest that the process & timeline be proposed by the HL staff to the TSC and affirmed by a vote, so that the TSC can ensure and represent to the wider community how it's happening and why it's trustworthy. 2) Along with getting TSC formal approval, it would be helpful to have two or three volunteer election observerswho are not running for the TSC, with whom we can CC on every election-related conversation we have or action we take, who can help us with the voter list, and with whom we can share the results from Condorcet. Apache has election monitors for this purpose. Those monitors, of course, will not have access to the raw votes, just as HL staff do not. 3) Perhaps the biggest source of public confusion, and the greatest amount of work for HL staff, was in creating the list of eligible voters from the myriad of different systems for collaboration, and then de-duping and correcting for invalid addresses. The charter describes an eligible voter very loosely: "anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase". It doesn't tightly define "codebase" nor does it say how much of a contribution is merited, so a one-line edit to the wiki or reporting a bug would qualify. We are happy to see the TSC looking at redefining who's allowed to vote. In Apache, only actual members of the ASF can vote on their board, and there is always a known good email address for reaching someone, and that persists even when individuals change jobs/employers. In addition to other criteria like "easy to describe" and "perceived as fair and hard to game", we would also ask that "easily resolvable to a working email address" be a part of the decision on who's eligible to vote. Any substantive change to eligibility requirements should also be turned into a proposed amendment to the Charter. 4) Regarding nominations: we recommend moving back to public nominations posted to the TSC list, backed with wiki page from the nominee, rather than collecting by form then posting to the wiki at the start of the election. We also recommend doing away with formally nominating someone else to vote. There were three candidates nominated by others who withdrew their candidacy as they weren't aware they were being nominated. And we provided no window between the time we took nominations and the start of the election to verify. 5) Timing. There were some aspects of the election with tight turn-around times during a month, August, when many people are on vacations or otherwise distracted. It may be better to push TSC elections out a month or two; perhaps, use September to do the data collection to determine who's allowed to vote and take nominations, and then October to conduct the vote over a slightly longer period, to maximize potential participation. Hope this is helpful, Brian -- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf |
||||||||
|
|
||||||||
|
greg m
Brian,
It's hard to argue with such excellent ideas. Thank you, greg From: Brian Behlendorf Sent: 9/24/2019 11:05 PM To: tsc@... Subject: [Hyperledger TSC] TSC election suggestions Hi all, The HL staff involved in administering the recent TSC election recently met to discuss things we might want to do differently next year, as well as some suggestions we'd have for the TSC, to make next year's election even smoother. 1) It's clear there were some members of the community who felt underinformed about the election timeline and process. The Hyperledger Charter, section 4.II.a, says "The TSC shall approve the process and timing for nominations and elections held on an annual basis." We had created the 2019 Election wiki page and published a timeline there, and announced it on TSC calls, but could have done a better job in ensuring TSC acceptance and buy-in of the process and communication around it. Next time, we suggest that the process & timeline be proposed by the HL staff to the TSC and affirmed by a vote, so that the TSC can ensure and represent to the wider community how it's happening and why it's trustworthy. 2) Along with getting TSC formal approval, it would be helpful to have two or three volunteer election observers who are not running for the TSC, with whom we can CC on every election-related conversation we have or action we take, who can help us
with the voter list, and with whom we can share the results from Condorcet. Apache has election monitors for this purpose. Those monitors, of course, will not have access to the raw votes, just as HL staff do not. 3) Perhaps the biggest source of public confusion, and the greatest amount of work for HL staff, was in creating the list of eligible voters from the myriad of different systems for collaboration, and then de-duping and correcting for invalid addresses.
The charter describes an eligible voter very loosely: "anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase". It doesn't tightly define "codebase" nor does it say how much of a contribution
is merited, so a one-line edit to the wiki or reporting a bug would qualify. We are happy to see the TSC looking at
redefining who's allowed to vote. In Apache, only actual members of the ASF can vote on their board, and there is always a known good email address for reaching someone, and that persists even when individuals change jobs/employers. In addition to
other criteria like "easy to describe" and "perceived as fair and hard to game", we would also ask that "easily resolvable to a working email address" be a part of the decision on who's eligible to vote. Any substantive change to eligibility requirements
should also be turned into a proposed amendment to the Charter. 4) Regarding nominations: we recommend moving back to public nominations posted to the TSC list, backed with wiki page from the nominee, rather than collecting by form then posting to the wiki at the start of the election. We also recommend doing away with formally nominating someone else to vote. There were three candidates nominated by others who withdrew their candidacy as they weren't aware they were being nominated. And we provided no window between the time we took nominations and the start of the election to verify. 5) Timing. There were some aspects of the election with tight turn-around times during a month, August, when many people are on vacations or otherwise distracted. It may be better to push TSC elections out a month or two; perhaps, use September to do the data collection to determine who's allowed to vote and take nominations, and then October to conduct the vote over a slightly longer period, to maximize potential participation. Hope this is helpful, Brian-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf |
||||||||
|
|
||||||||
|
Brian Behlendorf
Hi all, The HL staff involved in administering the recent TSC election
recently met to discuss things we might want to do differently
next year, as well as some suggestions we'd have for the TSC, to
make next year's election even smoother. 1) It's clear there were some members of the community who felt underinformed about the election timeline and process. The Hyperledger Charter, section 4.II.a, says "The TSC shall approve the process and timing for nominations and elections held on an annual basis." We had created the 2019 Election wiki page and published a timeline there, and announced it on TSC calls, but could have done a better job in ensuring TSC acceptance and buy-in of the process and communication around it. Next time, we suggest that the process & timeline be proposed by the HL staff to the TSC and affirmed by a vote, so that the TSC can ensure and represent to the wider community how it's happening and why it's trustworthy. 2) Along with getting TSC formal approval, it would be helpful to
have two or three volunteer election observers who are not
running for the TSC, with whom we can CC on every election-related
conversation we have or action we take, who can help us with the
voter list, and with whom we can share the results from
Condorcet. Apache has election monitors for this purpose. Those
monitors, of course, will not have access to the raw votes, just
as HL staff do not. 3) Perhaps the biggest source of public confusion, and the
greatest amount of work for HL staff, was in creating the list of
eligible voters from the myriad of different systems for
collaboration, and then de-duping and correcting for invalid
addresses. The charter describes an eligible voter very loosely:
"anyone in the technical community that contributes code,
documentation or other technical artifacts to the HLP codebase".
It doesn't tightly define "codebase" nor does it say how much of a
contribution is merited, so a one-line edit to the wiki or
reporting a bug would qualify. We are happy to see the TSC
looking at redefining who's allowed to vote. In Apache,
only actual members of the ASF can vote on their board, and there
is always a known good email address for reaching someone, and
that persists even when individuals change jobs/employers. In
addition to other criteria like "easy to describe" and "perceived
as fair and hard to game", we would also ask that "easily
resolvable to a working email address" be a part of the
decision on who's eligible to vote. Any substantive change to
eligibility requirements should also be turned into a proposed
amendment to the Charter. 4) Regarding nominations: we recommend moving back to public nominations posted to the TSC list, backed with wiki page from the nominee, rather than collecting by form then posting to the wiki at the start of the election. We also recommend doing away with formally nominating someone else to vote. There were three candidates nominated by others who withdrew their candidacy as they weren't aware they were being nominated. And we provided no window between the time we took nominations and the start of the election to verify. 5) Timing. There were some aspects of the election with tight turn-around times during a month, August, when many people are on vacations or otherwise distracted. It may be better to push TSC elections out a month or two; perhaps, use September to do the data collection to determine who's allowed to vote and take nominations, and then October to conduct the vote over a slightly longer period, to maximize potential participation. Hope this is helpful, Brian-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf |
||||||||
|
|