Date   

CFP DEADLINE EXTENDED: Hyperledger Global Forum 2020

Jessica Rampen
 

Hello, 

We've extended the deadline to submit a talk for Hyperledger Global Forum 2020! You now have until next Friday, 10/4 to submit.

Submit your talk here: https://events.linuxfoundation.org/events/hyperledger-global-forum-2020/program/cfp/

Thanks, 

Jessica Rampen
Sr. Manager of Marketing Communications 
Hyperledger
650-787-3548


What is the role of a company that sponsors a top level project?

Ry Jones
 

What are the responsibilities? What are the roles?
I've started a wiki page to discuss.
Ry
--
Ry Jones
Community Architect, Hyperledger


Upcoming Event: Hyperledger Fabric Quarterly Update Due #tsc-project-update - Thu, 10/03/2019 #cal-reminder #tsc-project-update

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Fabric Quarterly Update Due #tsc-project-update

When: Thursday, 3 October 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Fabric update to the TSC was due 30 September, 2019, and it will be presented to the TSC on 3 October, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Upcoming Event: Hyperledger Architecture WG Quarterly Update Due #tsc-wg-update - Thu, 10/03/2019 #tsc-wg-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Architecture WG Quarterly Update Due #tsc-wg-update

When: Thursday, 3 October 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Architecture WG update to the TSC was due 30 September, 2019, and it will be reviewed by the TSC on 3 October, 2019. Please review the update at TSC Working Group Updates prior to the meeting and add your questions to the update.


Re: security vuln reporting policy in GH

Dave Huseby <dhuseby@...>
 

On Wed, Sep 25, 2019 at 7:53 AM Ry Jones <rjones@...> wrote:
Since this is a .md file in repo, delegating updates to that file as required to the maintainers of that repo makes sense to me.

It would also be pretty easy to roll out a default, as you described, and have maintainers update if they like?
Ry

Yes, exactly what I was thinking. Default sent

Dave


Re: TSC election suggestions

Swetha Repakula
 

+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


Re: security vuln reporting policy in GH

Ry Jones
 


On Wed, Sep 25, 2019 at 7:53 AM Ry Jones <rjones@...> wrote:
Since this is a .md file in repo, delegating updates to that file as required to the maintainers of that repo makes sense to me.

It would also be pretty easy to roll out a default, as you described, and have maintainers update if they like?
Ry


--
Ry Jones
Community Architect, Hyperledger


Re: TSC election suggestions

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 -----
From: "hmontgomery@..." <hmontgomery@...>
Sent by: tsc@...
To: mark wagner <mwagner@...>, Brian Behlendorf <bbehlendorf@...>
Cc: "tsc@..." <tsc@...>
Subject: [EXTERNAL] Re: [Hyperledger TSC] TSC election suggestions
Date: Wed, Sep 25, 2019 11:52 AM
 

+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:

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
Twitter: @brianbehlendorf



--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc

 

 


Re: TSC election suggestions

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:

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



--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc


Re: TSC election suggestions

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 -----
From: "mark wagner" <mwagner@...>
Sent by: tsc@...
To: Brian Behlendorf <bbehlendorf@...>
Cc: "tsc@..." <tsc@...>
Subject: [EXTERNAL] Re: [Hyperledger TSC] TSC election suggestions
Date: Wed, Sep 25, 2019 11:17 AM
 
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:

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

 

 



--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc
 


Re: TSC election suggestions

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:

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



--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc


Re: security vuln reporting policy in GH

Ry Jones
 

Since this is a .md file in repo, delegating updates to that file as required to the maintainers of that repo makes sense to me.

It would also be pretty easy to roll out a default, as you described, and have maintainers update if they like?
Ry

On Wed, Sep 25, 2019 at 6:56 AM Dave Huseby <dhuseby@...> wrote:
Here's more detail in my thinking. The informational section of the security policy should really just be a link back to the policy/info published on our wiki. As for the set of releases currently being supported, I'm concerned about the maintenance of that. Do you see the maintainers keeping that list up-to-date? I haven't looked at the GH API to see if there is a way for us to refresh it from the CI pipeline when changes to the supported releases are made. Ideally, we'd use Git tags to enumerate the currently supported releases of a given repo and the CI pipeline would run a task to re-generate this policy dock and update it via the GH API.

As I said before, this is a good idea. It never hurts to shout about our security policies on every platform to encourage interaction and contributions that are security focused.

Dave
--
Ry Jones
Community Architect, Hyperledger


Re: security vuln reporting policy in GH

Dave Huseby <dhuseby@...>
 

Here's more detail in my thinking. The informational section of the security policy should really just be a link back to the policy/info published on our wiki. As for the set of releases currently being supported, I'm concerned about the maintenance of that. Do you see the maintainers keeping that list up-to-date? I haven't looked at the GH API to see if there is a way for us to refresh it from the CI pipeline when changes to the supported releases are made. Ideally, we'd use Git tags to enumerate the currently supported releases of a given repo and the CI pipeline would run a task to re-generate this policy dock and update it via the GH API.

As I said before, this is a good idea. It never hurts to shout about our security policies on every platform to encourage interaction and contributions that are security focused.

Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


On Wed, Sep 25, 2019 at 5:48 AM Christopher Ferris <chris.ferris@...> wrote:
Bumping this topic for discussion. Adding to the wiki as well.

Chris

On Fri, Sep 6, 2019 at 11:40 AM Christopher Ferris <chris.ferris@...> wrote:
I know that GH has been reporting vulnerabilities in dependencies for a while now, but I see that they have also added the ability to publish your security vulnerability reporting process via the GH repository.


Seems to me that it would be A Good Thing (tm) to update all the Hyperledger repos with our process, with each project adding in the set of releases covered by the policy.


Thoughts?

Chris


Re: security vuln reporting policy in GH

Dave Huseby <dhuseby@...>
 

Thanks for the bump. I agree with you that it is a good idea. I'm not ignoring this. It's on the todo list.

Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


On Wed, Sep 25, 2019 at 5:48 AM Christopher Ferris <chris.ferris@...> wrote:
Bumping this topic for discussion. Adding to the wiki as well.

Chris

On Fri, Sep 6, 2019 at 11:40 AM Christopher Ferris <chris.ferris@...> wrote:
I know that GH has been reporting vulnerabilities in dependencies for a while now, but I see that they have also added the ability to publish your security vulnerability reporting process via the GH repository.


Seems to me that it would be A Good Thing (tm) to update all the Hyperledger repos with our process, with each project adding in the set of releases covered by the policy.


Thoughts?

Chris


Re: TSC election suggestions

Arnaud Le Hors
 

I agree, this all sounds good to me.
--
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





Re: security vuln reporting policy in GH

Christopher Ferris <chris.ferris@...>
 

Bumping this topic for discussion. Adding to the wiki as well.

Chris


On Fri, Sep 6, 2019 at 11:40 AM Christopher Ferris <chris.ferris@...> wrote:
I know that GH has been reporting vulnerabilities in dependencies for a while now, but I see that they have also added the ability to publish your security vulnerability reporting process via the GH repository.


Seems to me that it would be A Good Thing (tm) to update all the Hyperledger repos with our process, with each project adding in the set of releases covered by the policy.


Thoughts?

Chris


Hyperledger is part of the GitHub package registry

Ry Jones
 

In the last little while, the Hyperledger GitHub org has had the package beta enabled. This is new ground of all of us, so I've created a distinct org for testing GitHub Actions and GitHub Package Registry.

If you want to test it out, please get in touch with me directly and join us in #cicd so we can all work on this together.
Ry
--
Ry Jones
Community Architect, Hyperledger


Re: TSC election suggestions

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


TSC election suggestions

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


Upcoming Event: Hyperledger Caliper Quarterly Update Due #tsc-project-update - Thu, 09/26/2019 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Caliper Quarterly Update Due #tsc-project-update

When: Thursday, 26 September 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Caliper update to the TSC was due 23 September, 2019, and it will be presented to the TSC on 26 September, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.

1201 - 1220 of 3898