Date   

Re: Proposal to the TSC: enable 2FA requirement across all orgs

Christopher Ferris <chrisfer@...>
 

You should give a warning. You can add all github ids to a team and @ the team. Maybe give a few days to remediate. I approve subject to advance warning and update to contributors guides.

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris

On May 30, 2019, at 4:54 PM, Ry Jones <rjones@...> wrote:

In light of recent discussions on this mailing list, I ask the TSC to vote by email on enabling 2FA for the Hyperledger and Hyperledger Labs orgs.

We will lose many members that are committers. It will cause turbulence.
Ry
--
Ry Jones
Community Architect, Hyperledger


Re: Proposal to the TSC: enable 2FA requirement across all orgs

Middleton, Dan <dan.middleton@...>
 

Let’s stay the vote. We can bring this up as a topic in the next TSC call and either take a vote there or move to email vote thereafter.

There’s not yet enough discussion on the turbulence for an informed vote.

 

Thanks,
Dan

 

From: <tsc@...> on behalf of Ry Jones <rjones@...>
Date: Thursday, May 30, 2019 at 3:54 PM
To: TSC <tsc@...>
Subject: [Hyperledger TSC] Proposal to the TSC: enable 2FA requirement across all orgs

 

In light of recent discussions on this mailing list, I ask the TSC to vote by email on enabling 2FA for the Hyperledger and Hyperledger Labs orgs.

 

We will lose many members that are committers. It will cause turbulence.

Ry
--

Ry Jones

Community Architect, Hyperledger


Proposal to the TSC: enable 2FA requirement across all orgs

Ry Jones
 

In light of recent discussions on this mailing list, I ask the TSC to vote by email on enabling 2FA for the Hyperledger and Hyperledger Labs orgs.

We will lose many members that are committers. It will cause turbulence.
Ry
--
Ry Jones
Community Architect, Hyperledger


Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Isn’t 2FA standard these days for this kind of thing?  Is there anything we can do to push contributors to set it up?  I’d have pushed the button…

 

From: tsc@... [mailto:tsc@...] On Behalf Of Christopher Ferris
Sent: Thursday, May 30, 2019 1:22 PM
To: Ry Jones <rjones@...>
Cc: Shawn Amundson <amundson@...>; TSC <tsc@...>
Subject: Re: [Hyperledger TSC] Proposal: adopt the Kubernetes GitHub/Community management workflow

 

I’d insist on all ppl with write and admin access to have 2FA. I would also make STRONG recommendation for others to do so as well. I too have been tempted to push the button, but that would only end in a flooded inbox with hate mail;-)

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris


On May 30, 2019, at 4:08 PM, Ry Jones <rjones@...> wrote:

1. Nobody ever asked for that; I thought it came for free. I added all repos to the "Hyperledger Contributors" group (which should be everyone) as "read". You should see this reflected; I checked a few repos before and after, and it looks how I expect. If you do not see this, let me know.

2. Yes

3. My concern is, honestly, booting everyone that doesn't have 2FA enabled, which is a lot of contributors. I've been tempted to click the button, but I haven't. I suspect the answer is "yes" but we'll need somewhere to host it (GCE or AWS, probably, for production; I'm sure I have a machine that can run minikube that I can dedicate to the cause

 

before I started spending a lot of time on it, I wanted to see if we could reach consensus.

 

On Thu, May 30, 2019 at 12:32 PM Shawn Amundson <amundson@...> wrote:

I'm not sure I fully grok everything there, given the amount of kubernetes-specific stuff (staging vs. non-staging repos, etc.).

 

There are a couple things there I really like (if I'm understanding it correctly):

 

1. By default, everyone in the org having read access to all repos. That would be awesome.

2. For our repos w/MAINTAINERS.md files, we should be able to derive write access programatically (into the tool's format), then apply it programatically. That would be awesome.

 

There are other good things in there too.

 

Would it be possible to pilot this on a few repos so we could gain a better understanding of it, or will this be a heavy lift to try it out?

 

-Shawn

 

On Wed, May 29, 2019 at 6:13 PM Ry Jones <rjones@...> wrote:

Much of this would not apply - we don't have a CLA, for instance. However:

https://github.com/kubernetes/community/tree/master/github-management

would make on-boarding new users more programmatic. Also:

Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

 

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.

Ry

--

Ry Jones

Community Architect, Hyperledger



--

Ry Jones

Community Architect, Hyperledger

 


Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

Christopher Ferris <chrisfer@...>
 

I’d insist on all ppl with write and admin access to have 2FA. I would also make STRONG recommendation for others to do so as well. I too have been tempted to push the button, but that would only end in a flooded inbox with hate mail;-)

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris

On May 30, 2019, at 4:08 PM, Ry Jones <rjones@...> wrote:

1. Nobody ever asked for that; I thought it came for free. I added all repos to the "Hyperledger Contributors" group (which should be everyone) as "read". You should see this reflected; I checked a few repos before and after, and it looks how I expect. If you do not see this, let me know.
2. Yes
3. My concern is, honestly, booting everyone that doesn't have 2FA enabled, which is a lot of contributors. I've been tempted to click the button, but I haven't. I suspect the answer is "yes" but we'll need somewhere to host it (GCE or AWS, probably, for production; I'm sure I have a machine that can run minikube that I can dedicate to the cause

before I started spending a lot of time on it, I wanted to see if we could reach consensus.

On Thu, May 30, 2019 at 12:32 PM Shawn Amundson <amundson@...> wrote:
I'm not sure I fully grok everything there, given the amount of kubernetes-specific stuff (staging vs. non-staging repos, etc.).

There are a couple things there I really like (if I'm understanding it correctly):

1. By default, everyone in the org having read access to all repos. That would be awesome.
2. For our repos w/MAINTAINERS.md files, we should be able to derive write access programatically (into the tool's format), then apply it programatically. That would be awesome.

There are other good things in there too.

Would it be possible to pilot this on a few repos so we could gain a better understanding of it, or will this be a heavy lift to try it out?

-Shawn

On Wed, May 29, 2019 at 6:13 PM Ry Jones <rjones@...> wrote:
Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger



--
Ry Jones
Community Architect, Hyperledger


Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

Ry Jones
 

1. Nobody ever asked for that; I thought it came for free. I added all repos to the "Hyperledger Contributors" group (which should be everyone) as "read". You should see this reflected; I checked a few repos before and after, and it looks how I expect. If you do not see this, let me know.
2. Yes
3. My concern is, honestly, booting everyone that doesn't have 2FA enabled, which is a lot of contributors. I've been tempted to click the button, but I haven't. I suspect the answer is "yes" but we'll need somewhere to host it (GCE or AWS, probably, for production; I'm sure I have a machine that can run minikube that I can dedicate to the cause

before I started spending a lot of time on it, I wanted to see if we could reach consensus.


On Thu, May 30, 2019 at 12:32 PM Shawn Amundson <amundson@...> wrote:
I'm not sure I fully grok everything there, given the amount of kubernetes-specific stuff (staging vs. non-staging repos, etc.).

There are a couple things there I really like (if I'm understanding it correctly):

1. By default, everyone in the org having read access to all repos. That would be awesome.
2. For our repos w/MAINTAINERS.md files, we should be able to derive write access programatically (into the tool's format), then apply it programatically. That would be awesome.

There are other good things in there too.

Would it be possible to pilot this on a few repos so we could gain a better understanding of it, or will this be a heavy lift to try it out?

-Shawn

On Wed, May 29, 2019 at 6:13 PM Ry Jones <rjones@...> wrote:
Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger



--
Ry Jones
Community Architect, Hyperledger


Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

Shawn Amundson
 

I'm not sure I fully grok everything there, given the amount of kubernetes-specific stuff (staging vs. non-staging repos, etc.).

There are a couple things there I really like (if I'm understanding it correctly):

1. By default, everyone in the org having read access to all repos. That would be awesome.
2. For our repos w/MAINTAINERS.md files, we should be able to derive write access programatically (into the tool's format), then apply it programatically. That would be awesome.

There are other good things in there too.

Would it be possible to pilot this on a few repos so we could gain a better understanding of it, or will this be a heavy lift to try it out?

-Shawn

On Wed, May 29, 2019 at 6:13 PM Ry Jones <rjones@...> wrote:
Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger


Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

Ry Jones
 

On Thu, May 30, 2019 at 4:57 AM Casey Kuhlman via Lists.Hyperledger.Org <casey=monax.io@...> wrote:
As a contributor to both I can say that the Kubernetes system feels (a) baked, (b) friendly (or at least less human in a bad way), and (c) cohesive across repos and projects; whereas Hyperledger feels... less so.

Completely agreed. We're where we are, I want to fix it, help?
--
Ry Jones
Community Architect, Hyperledger


Due to conflict, I will not be able to attend TSC meeting today

binh nguyen
 

I will review the minutes and any action items.

Thanks,
Binh


Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

Casey Kuhlman
 

As a contributor to both I can say that the Kubernetes system feels (a) baked, (b) friendly (or at least less human in a bad way), and (c) cohesive across repos and projects; whereas Hyperledger feels... less so.
____________________________________

Casey Kuhlman, Monax
CEO
Email: casey@... 
Phone (US): +1-423-523-9531(UK): +44-75-073-96359
____________________________________


On Thu, May 30, 2019 at 5:09 AM Baohua Yang <yangbaohua@...> wrote:
Prefer the more-automatic way!

On Thu, May 30, 2019 at 7:13 AM Ry Jones <rjones@...> wrote:
Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger



--
Best wishes!

Baohua Yang


Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

Baohua Yang
 

Prefer the more-automatic way!


On Thu, May 30, 2019 at 7:13 AM Ry Jones <rjones@...> wrote:
Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger



--
Best wishes!

Baohua Yang


5/23 TSC meeting minutes are up

Dave Huseby <dhuseby@...>
 

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


Proposal: adopt the Kubernetes GitHub/Community management workflow

Ry Jones
 

Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger


TSC minutes for 5/9 are up

Dave Huseby <dhuseby@...>
 

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


Confluence and JIRA integration you can do today

Dave Huseby <dhuseby@...>
 

Hi TSC,

While transcribing the notes from the 5/9 TSC call, there's a point where Shawn Amundson says they'd like a way to aggregate all of the JIRA tasks that their team members are working on. Right now we can already embed JIRA search results on Confluence pages. So my solution to Shawn was to use the JIRA embed plus the "include page" macro to create custom dashboards in Confluence.

I built something similar last week. I organized all of the audit results data on our wiki by creating two pages in each project, one called "Audits" and another called "Repos". The Audits page in each project includes links to the audit results as well as an embedded JIRA search showing the JIRA bugs for fixing the licensing audit issues found. The Repos page just includes a list of the git repos for the given project.  Here are the Audits and Repo pages for Sawtooth as an example:


I then created a single Project Audits page under the top-level Projects heading that aggregates all of the project pages into a single page using the "include page" macro:


This technique could be used by each wiki user to create a dashboard in their personal space that aggregates their assigned JIRA tasks for multiple projects and other kids of things. Then each project could aggregate the dashboards of each project member. All of this we can do right now and with the new contractor coming on board, I'm sure it will get even better.

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


ID WG Notes and calling all APAC members. 01:00 UTC on May 30th.

Vipin Bharathan
 

Hello Everyone,
I have added the notes for the first meeting we had
Along with the list of participants and condensed notes, we also have the links to the audio and video recordings and links to Drummond's presentation as well as other material related to FATF.
We will have another call within 3 hours and 21 minutes with the same agenda. (01:00 UTC)

We already have a tentative Agenda for the next call on June 12

- Ajay Yadhav from Ayanworks (the latest Sovrin steward) on the Consent layer (part of the India Stack)
-Luca Boldrin on Ledger in SSI (needed or not needed)

So exciting to be part of the Identity WG. In the meantime we are advancing the paper as well.


Vipin

On Wed, May 29, 2019 at 1:24 PM Stephane MOUY <sgmouy@...> wrote:

Dear all,

 

Further to our discussion today on the FATF work regarding virtual assets & digital IDs, see below two links which you may find interesting.

 

http://www.fatf-gafi.org/publications/fatfrecommendations/documents/regulation-virtual-assets-interpretive-note.html

http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html

 

I also attach a short presentation of the Digital ID workshop which took place in Vienna on May 6th.

 

With kind regards.

 

Stéphane

 

 

De : identity-wg@... <identity-wg@...> De la part de Ajay Jadhav (AyanWorks) via Lists.Hyperledger.Org
Envoyé : mercredi 29 mai 2019 17:40
À : Identity-WG@...; Hyperledger List <tsc@...>; Vipin Bharathan <vipinsun@...>
Cc : identity-wg@...
Objet : Re: [Hyperledger Identity WG] Identity WG calls tomorrow May 29th

 

Hi Vipin,

 

Extremely sorry for the last minute update. I will be able to present on the Consent Layer in the next Identity WG meeting for sure.

Please let me know if that works.

--
Best Regards,
Ajay Jadhav

 

 

On Wednesday, May 29, 2019, 5:12:46 AM GMT+5:30, Vipin Bharathan <vipinsun@...> wrote:

 

 

Hi all,

Identity WG will continue its two calls schedule for May 29th/30th that would be 4 pm UTC and 01:00 AM UTC (May 30th for UTC and points East)

Agenda: 

-Drummond Reed on IIW as well as Consensus 2019
-FATF report by Stephane Mouy (FATF is the global KYC/AML recommendation body) (I will echo the report at the 9 pm call)
-India Consent Layer Ajay Jadhav
-Work on the paper

Multiple calls at different times with the same Agenda. This is an attempt to escape the time zone limitations of our calls.

4 pm UTC is good for The whole of North and South America as well as Europe and possibly parts of the near East.

01:00 am UTC the whole of East Asia, Australia etc. (this would be the next day for all points UTC and East)

We are still fiddling with these dates and times. 

Join from PC, Mac, Linux, iOS or Android: 
https://zoom.us/my/hyperledger.community

All are welcome.-

The paper is: 
https://docs.google.com/document/d/1ExFNRx-yYoS8FnDIUX1_0UBMha9TvQkfts2kVnDc4KE/edit#

Meeting minutes:
We are taking the minutes on the wiki now. ( 
https://wiki.hyperledger.org/display/IWG/2019-05-29+Notes ) Please edit collaboratively or send updates by email. 
You need a LF ID to login to edit.
To read passively you do not need a LFID

All are welcome. You do not have to be a member of Hyperledger to be on the call!

zoom details 
iPhone one-tap :

US: 
+16465588656,,4034983298# or +16699006833,,4034983298#

Or Telephone:
Dial(for higher quality, dial a number based on your current location):

US: 
+1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)

Meeting ID: 
403 498 3298

International numbers available: 
https://zoom.us/u/bAaJoyznpThis is an open call. 

Please reach out if you have questions, attend the call, participate to collaborate!


Re: [Hyperledger Identity WG] Identity WG calls tomorrow May 29th

Stephane MOUY <sgmouy@...>
 

Dear all,

 

Further to our discussion today on the FATF work regarding virtual assets & digital IDs, see below two links which you may find interesting.

 

http://www.fatf-gafi.org/publications/fatfrecommendations/documents/regulation-virtual-assets-interpretive-note.html

http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html

 

I also attach a short presentation of the Digital ID workshop which took place in Vienna on May 6th.

 

With kind regards.

 

Stéphane

 

 

De : identity-wg@... <identity-wg@...> De la part de Ajay Jadhav (AyanWorks) via Lists.Hyperledger.Org
Envoyé : mercredi 29 mai 2019 17:40
À : Identity-WG@...; Hyperledger List <tsc@...>; Vipin Bharathan <vipinsun@...>
Cc : identity-wg@...
Objet : Re: [Hyperledger Identity WG] Identity WG calls tomorrow May 29th

 

Hi Vipin,

 

Extremely sorry for the last minute update. I will be able to present on the Consent Layer in the next Identity WG meeting for sure.

Please let me know if that works.

--
Best Regards,
Ajay Jadhav

 

 

On Wednesday, May 29, 2019, 5:12:46 AM GMT+5:30, Vipin Bharathan <vipinsun@...> wrote:

 

 

Hi all,

Identity WG will continue its two calls schedule for May 29th/30th that would be 4 pm UTC and 01:00 AM UTC (May 30th for UTC and points East)

Agenda: 

-Drummond Reed on IIW as well as Consensus 2019
-FATF report by Stephane Mouy (FATF is the global KYC/AML recommendation body) (I will echo the report at the 9 pm call)
-India Consent Layer Ajay Jadhav
-Work on the paper

Multiple calls at different times with the same Agenda. This is an attempt to escape the time zone limitations of our calls.

4 pm UTC is good for The whole of North and South America as well as Europe and possibly parts of the near East.

01:00 am UTC the whole of East Asia, Australia etc. (this would be the next day for all points UTC and East)

We are still fiddling with these dates and times. 

Join from PC, Mac, Linux, iOS or Android: 
https://zoom.us/my/hyperledger.community

All are welcome.-

The paper is: 
https://docs.google.com/document/d/1ExFNRx-yYoS8FnDIUX1_0UBMha9TvQkfts2kVnDc4KE/edit#

Meeting minutes:
We are taking the minutes on the wiki now. ( 
https://wiki.hyperledger.org/display/IWG/2019-05-29+Notes ) Please edit collaboratively or send updates by email. 
You need a LF ID to login to edit.
To read passively you do not need a LFID

All are welcome. You do not have to be a member of Hyperledger to be on the call!

zoom details 
iPhone one-tap :

US: 
+16465588656,,4034983298# or +16699006833,,4034983298#

Or Telephone:
Dial(for higher quality, dial a number based on your current location):

US: 
+1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)

Meeting ID: 
403 498 3298

International numbers available: 
https://zoom.us/u/bAaJoyznpThis is an open call. 

Please reach out if you have questions, attend the call, participate to collaborate!


Perf and Scale discussion on upcoming TSC call - please attend

mark wagner <mwagner@...>
 

Hi

Sorry to blast to several lists.

Based on the recent Performance and Scale Working Group (PSWG) quarterly report, we plan to have a discussion on the future direction of the PSWG at this Thurs Technical Steering Committee (TSC) meeting (10 AM EDT, see calendar for more call details)

I would encourage anyone with an interest in Performance and Scalability to attend the call and join the discussion, or share your thoughts as a response to this email.

thanks

--
Mark Wagner
Chair - Hyperledger Performance and Scale Working Group


Re: [Hyperledger Identity WG] Identity WG calls tomorrow May 29th

Ajay Jadhav (AyanWorks)
 

Hi Vipin,

Extremely sorry for the last minute update. I will be able to present on the Consent Layer in the next Identity WG meeting for sure.
Please let me know if that works.

--
Best Regards,
Ajay Jadhav



On Wednesday, May 29, 2019, 5:12:46 AM GMT+5:30, Vipin Bharathan <vipinsun@...> wrote:


Hi all,
Identity WG will continue its two calls schedule for May 29th/30th that would be 4 pm UTC and 01:00 AM UTC (May 30th for UTC and points East)

Agenda: 

-Drummond Reed on IIW as well as Consensus 2019
-FATF report by Stephane Mouy (FATF is the global KYC/AML recommendation body) (I will echo the report at the 9 pm call)
-India Consent Layer Ajay Jadhav
-Work on the paper

Multiple calls at different times with the same Agenda. This is an attempt to escape the time zone limitations of our calls.

4 pm UTC is good for The whole of North and South America as well as Europe and possibly parts of the near East.

01:00 am UTC the whole of East Asia, Australia etc. (this would be the next day for all points UTC and East)

We are still fiddling with these dates and times. 

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community

All are welcome.-

The paper is: https://docs.google.com/document/d/1ExFNRx-yYoS8FnDIUX1_0UBMha9TvQkfts2kVnDc4KE/edit#

Meeting minutes:
We are taking the minutes on the wiki now. ( https://wiki.hyperledger.org/display/IWG/2019-05-29+Notes ) Please edit collaboratively or send updates by email. 
You need a LF ID to login to edit.
To read passively you do not need a LFID

All are welcome. You do not have to be a member of Hyperledger to be on the call!

zoom details 
iPhone one-tap :

US: +16465588656,,4034983298# or +16699006833,,4034983298#

Or Telephone:
Dial(for higher quality, dial a number based on your current location):

US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)

Meeting ID: 403 498 3298

International numbers available: https://zoom.us/u/bAaJoyznpThis is an open call. 

Please reach out if you have questions, attend the call, participate to collaborate!


Re: Project Lifecycle taskforce

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

I’ve talked way too much about this to not be stuck with at least some of the dirty work.  Thanks for organizing Arnaud, and count me in.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Ry Jones
Sent: Tuesday, May 28, 2019 8:27 AM
To: Arnaud Le Hors <lehors@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Project Lifecycle taskforce

 

 

On Tue, May 28, 2019 at 4:57 AM Arnaud Le Hors <lehors@...> wrote:

Hi all,
I accepted last week to take the leadership on having another look at the Project Lifecycle to try and come up with a proposal to address the gaps that have surfaced over the last several months.
For now, it's just Mic and me but if you feel an urge to take part in shaping up a proposal, please, let me know.
Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM



--

Ry Jones

Community Architect, Hyperledger

1601 - 1620 of 3898