Date   

Smart contracts working group

Sofia Terzi <sterzi@...>
 

Hello,


I have made a proposal for the smart contracts working group and send an email before a couple of days. I wanted to know if there is going to be a meeting tomorrow in order to present it to the committee as it is described in the process. Thank you


Best,

Sofia Terzi


Send from android Sony Xperia


Re: CI/CD for Hyperledger projects

Jonathan Levi (HACERA)
 

Adding the HL Fabric team, in case there are new issues that I was not aware of.


Jonathan Levi
HACERA
  -  To Blockchain with Confidence


On Thu, Jan 24, 2019, 12:41 AM Jonathan Levi (HACERA) <jonathan@... wrote:
Hi everybody,

This is really great - thanks.

1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 

Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.

2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.

Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.

We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.

However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.

In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.

I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.


Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?


I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?

Thanks, 

Jonathan Levi
HACERA
  -  To Blockchain with Confidence

Unbounded  To Network with Networks

M  +1.650.686.9029








On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.

I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.

I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry




Re: CI/CD for Hyperledger projects

Jonathan Levi (HACERA)
 

Hi everybody,

This is really great - thanks.

1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 

Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.

2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.

Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.

We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.

However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.

In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.

I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.


Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?


I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?

Thanks, 

Jonathan Levi
HACERA
  -  To Blockchain with Confidence

Unbounded  To Network with Networks

M  +1.650.686.9029








On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.

I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.

I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry




Re: CI/CD for Hyperledger projects

Ry Jones
 

Nikolai,
Great. I look forward to working with you to make Hyperledger's Jenkins useful to the broader community.
Ry


On Wed, Jan 23, 2019 at 11:45 AM Iushkevich Nikolai <nikolai@...> wrote:
Hi Ry!

In HL Iroha we also heavily use Jenkins. We would love to contribute to the process, I cc’ed our DevOps engineers to the thread.

Nikolai


--
Ry Jones
Community Architect, Hyperledger
Chat: @ry


Re: CI/CD for Hyperledger projects

Nikolay Yushkevich <nikolai@...>
 

Hi Ry!

In HL Iroha we also heavily use Jenkins. We would love to contribute to the process, I cc’ed our DevOps engineers to the thread.

Nikolai

Project manager at Soramitsu

On 23 Jan 2019, at 22:37, Ry Jones <rjones@...> wrote:

Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.

I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.

I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry


CI/CD for Hyperledger projects

Ry Jones
 

Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.

I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.

I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry


Agenda for 24 January 2019

Ry Jones
 

Announcement:

Discussion:

Quarterly updates:

Delayed quarterly updates:

Backlog:


--
Ry Jones
Community Architect, Hyperledger
Chat: @ry


2019 Q1 Hyperledger Iroha

Nikolay Yushkevich <nikolai@...>
 

Dear TSC members,

I’ve replaced the link on wiki.hyperledger.org in order to resolve any possible confusion.

I failed to transfer report to docuwiki from Confluence as I am unable to create a page there :) 

Nikolai

Project manager at Soramitsu  


New WorkGroup proposal "Smart Contracts"

Sofia Terzi <sterzi@...>
 

Dear Mrs/Mr,

 

I have created a proposal for a Smart Contracts workgroup. I am personally interested as a researcher and blockchain solutions architect/developer, but I believe that it is a hot topic for the blockchain ecosystem and many others will be interested and involved. Please review my proposal and let me know for the next steps. I am at your disposal

 

The link for the proposal is   https://wiki2.hyperledger.org/display/HYP/Smart+Contracts

 

Best Regards,

Sofia Terzi

____________________________________________________________________

Software Solutions Architect Msc. – Research Associate@CERTH/ITI - PhD Student@CSD AUTh

Information Technologies Institute – CERTH

6th km Harilaou - Thermi, 57001, Thessaloniki, Greece

 


Re: Hyperledger BootCamp in Hong Kong Mar 7,9 2019

Silona Bonewald <sbonewald@...>
 

Thank you Hart - I am trying to figure it out in regards to communication.

On the bootcamps, there is a BIG focus on planning in advance on the wiki and getting the participants to give feedback there also.
This means - the agenda will grow as people come on board in regards to their contributions.
https://wiki2.hyperledger.org/display/events/HLbootcampHK-Agenda  I hope that to have at least 7 scoped out by the end of this week to be good examples.  

Doing advanced planning is a heavier lift for my team - but I have found it to be more consistent quality wise than hackathons.  I am also calling them bootcamps because of the emphasis on onboarding newbies.  Obviously other things can take place and will.  But first, we really need to get our community to be more friendly and accessible to others.  I'm sure for the China bootcamp there will be a big discussion will be about translations and working with truly international teams.  I also personally find the competitive nature of hackathons often hurts the community building that is our major objective.

Bootcamps are not just about coding.  OSS communities live longer when there is a greater diversity of roles.  If someone works on design, videos or documentation, and contributes it - that also needs acknowledgement.  If someone helps with recruiting or promotion, they also need to be acknowledged.  When I say contributions - this is what I mean - not that everyone will get a PR thru.  I am assuming most of the PR's that make it through will be documentation in focus since testing takes time. But remember, some of the new projects may be attending so you never know about the code level PRs making it through.

Hopefully this is clear on the bootcamps page. https://wiki2.hyperledger.org/display/events/Bootcamps
Study groups

Hart - I added some of your questions to the Survey for Post event.   https://wiki2.hyperledger.org/display/events/Post-Event+Survey
But since it is only two days - i really don't see people having time to do multiple platforms.   Unless someone does a Breakout session on exactly that.   But I will ask about Projects in general.

Thanks!
Silona

On Mon, Jan 21, 2019 at 3:09 PM Montgomery, Hart <hmontgomery@...> wrote:

Hi Silona,

 

Thanks for the email—and no need to apologize!  I think we’re headed in the right direction on this.  I think most people (myself included) were just a little surprised by the suddenness of this whole thing.  Of course, not having TSC meetings for a month and a half probably didn’t help things either.

 

Would it be possible to put up a  more  detailed tentative agenda in the near future?  My experience with hackfests has been that more people will show up (particularly from the core group) if there is something concrete on the agenda that they are interested in working on.  This might not be the easiest thing to do months in advance, but I think it helps drive attendance.  The more details we can put in the agenda, the better.

 

I think the current proposal for an agenda is probably too ambitious for a boot camp, and I would be very surprised if new people landed code commits (for reference, the only time I can remember total newbies landing commits was in the first six months of the project—maybe there have been others that I don’t know about).  Do we have good statistics on who is attending?  Based on historic data, I would be surprised if even half of the people attending came ready to code and, for most of those who are ready to code, just setting up and using the projects/platforms is all they really want to do.  I’m sure there will be some exceptions (I’m really hoping some Ursa people are an exception here), but I think this is something that we should probably plan to think about.

 

I think it would be a great idea if we could gather really detailed statistics from this event.  How many people (actually) showed up?  How many people came with a dev environment on their laptop?  How many actually set up a project?  How many attempted some coding?  Who (if anyone) landed PRs?  What platforms did they use?  Did anyone set up multiple platforms?  This would hopefully allow us to tailor these events more in the future, even if we had to approximate these and do some counting by hand. 

 

Before I ramble even further, thanks again for tinkering with the hackfest structure and moving it forward.  We’ve literally had the exact same discussion probably ten times over the past few years about how we can improve hackfests, and we haven’t changed much of anything, so shaking up things seems to be the right move.  I hope that we can iterate and get to something that makes everyone happy.

 

Thanks,

Hart

 

From: Silona Bonewald [mailto:sbonewald@...]
Sent: Saturday, January 19, 2019 6:38 PM
To: Vipin Bharathan <vipinsun@...>
Cc: Montgomery, Hart <hmontgomery@...>; Brian Behlendorf <bbehlendorf@...>; tsc@...
Subject: Re: [Hyperledger TSC] Hyperledger BootCamp in Hong Kong Mar 7,9 2019

 

 

This is a Mea Culpa email.   Ignorance isn't an excuse but I did want to explain the thinking behind what happened.  It's my mistake and I'm sorry for the confusion I caused by not keeping everyone informed.  Going forward, I'm gonna be sending a lot more little emails to this group.

 

I viewed the new Maintainers/Contributors Summit as the actual HackFest replacement TSC attendance wise.  A Summit is more of an "All Hands on Deck" type of an event.  I felt like I was postponing the "HackFest" pending reworking into a summit/think tank style structure.  I asked Tracy to very quickly post a proposal to the wiki so that we could start discussing it as a community and we could discuss it at the TSC meeting.

 

I did not view the bootcamp as a replacement other than - we still needed to take advantage of the timing and free space Julian obtained for us.  My decision was primarily driven by the fact we didn't feel like we could organize a complete and effective HackFest in time.  We did not have a date or location until a week ago.  The location opened up and we had to jump on it FAST!  So I compromised.  This did cause some confusion hence Ry saying "HackFest is cancelled" even though we closed the contract with the venue at the same time for a bootcamp.   The real answer is a good deal more complex than that...

 

I received primarily negative feedback about the current state of the HackFests during HGF.  My team and Julian had a deep conversation about what we thought the APAC market would need in an event.  We discussed the chicken and egg problem of how hard it is for most maintainers to travel to APAC but not really having enough local maintainers to really make a HackFest work on a short notice.  Julian said one of his main issues was getting people from the over 50 APAC member companies on-boarded and participating in the community.  I suggested taking advantage of the free space he had just found with doing a bootcamp instead of a HackFest.  It would be our first bootcamp.  It might be a little rough but better than not having an event.

 

This would give us time to work on reframing the HackFest into an event that has a few clearly defined deliverables like a Summit/Think Tank. 

 

We were already designing a generalized bootcamp formula.  My CA team realized we needed a recruiting/onboarding style event to be done regularly and distributed for our contributors and potential contributors.  We wanted more on-boarding style events to take place this year.  But we wanted a safer structure than the hackathons.  We started planning on-boarding events in India, S America and maybe Singapore for this year. 

 

The Indy and Ursa projects liked the idea of training bootcamps so much they asked if they could do a "one off" version.  Since my team was already talking about how to standardize it.  I decided to work with them on theirs.  We are discussing what the future approval process will be.  I felt safe working with these two teams because both projects did similar 4hr formats at the HGF.  We wanted to iterate on it and make it stronger!  So I viewed bootcamps as something new.  I did not see them as a HackFest replacement attendance wise.  I saw the bootcamps as a way for getting measurable participation and overcoming that scary "First edit" or "first Commit" and the thrill of the first acceptance.  I also saw it as a way for our maintainers to see first hand the affects they have on the newbies. Those people will go on to participate more and the maintainers can take a clearer mentorship role.

 

A bootcamp doesn't require the complete coverage of all HL's maintainers.  There could be many bootcamps.  Bootcamps have an inclusive model so people can self organize based on the resources available.  I view them as merger of a codeathon/unconference/training session.  The key takeaway from a codeathon is the wiki pre-planning. So for the bootcamps we will pre-planning the breakout sessions. Like an unconference, the attendees decide what those breakout sessions will be.  And we will as a team, target people ready and willing to onboard new people.   There is much flexibility built in regards to the scheduling on the breakouts.  So as Brian says, if a bunch arrives and decides to do a hard core session, they can.  The sign up spreadsheet for the Breakouts will indicate things like Level, Language, prereq, software needed, etc.

 

For this bootcamp in HK,  I am talking with Indy, Ursa, Cello, Caliper, the China Tech WG, and others about possible sessions.  They will each get planning pages on the wiki as we move forward.  We will be figuring out things like, size, timing, and placement of those sessions.  Dorothy and I have been talking with Marketing to see all the general materials cranked out by Tuesday.   She and I are also working with Events to nail down logistics and get registration ready by Tuesday. 

 

It is a BIG lift for the LF team to make this deadline.  Maybe I should have said "No" and decided to wait until April/May for a different event in APAC and possibly it could have been a summit.  But I wanted to do something in March even if it is a smaller event.  I really wanted to start iterating on it and taking advantage of the location and timing.  I may be over confident but I have run similar but much larger events in the past, so I think we can do it.

 

We have an EXTREMELY short window to get marketing and registration done before Feb 4th (which is really Jan 28th.)  Registration and marketing starts on the 22nd.  But after that, we focus on mentoring people on creating the breakout sessions.  These sessions are where my team will need the most help from the TSC in regards to recruiting. 

 

Having run several hardware startups, I am properly terrified of Chinese New Year.  It's hard to explain how thoroughly things shut down... even a couple of weeks advance becomes CRUNCH time.  Getting the possible attendee's attention in the next week and half is going to be a very heavy lift for Julian and his team.  I was distracted by all the logistics I had to get in focus quickly. So I did not inform the TSC.  I was also a bit to focused on getting very basic documentation up on the wiki before sending an email explaining the situation. But it is up and we are live editing it!  I hope it will be more polished by Tuesday!  https://wiki2.hyperledger.org/display/events/Hyperledger+BootCamp+-+Hong+Kong

 

As to Vipin's checklist,  these are all things we have been discussing organizationally for the bootcamps!   I will ask that for those discussions on the bootcamps that we have them publicly on the wiki.  You can do inline comments!  Right now I have the other members outside of HL staff that will be running bootcamps asking similar questions.  I don't want to lose these ideas esp the possible sessions. I would like them to be findable by the participant and organizers.  We might not be able to implement all of the ideas at each Bootcamp.   But they are inspiring to the person wanting to do a breakout session at the NEXT one!  I for one am very interested in posting re-usable training materials.  I believe Indy is already on it and will be sharing theirs so we can post links to them once created.

 

Also Hart - you are 100% right about tying the bootcamps to other events to help with maintainers' budget.  There is a big blockchain event in HK at the same time as this bootcamp on Mar 7th, 8th.  Julian is hoping to use it to his advantage :-)  If you are attending this conference in HK - we will ask you about leading a session!  The one-off bootcamps are also tied to events such as a BC govt event, Denver startup event w 18K people, and DefCon.  I used to do all my similar style events at SXSW and I always had a very full house :-)

 

I hope the site will be live on Tuesday and when it is - I will post it here to the list so we can all help promote it.

 

As for the postponed HackFest/Summit,  I'm glad to see the discussion here on the mailing list. 

 

Thank you for understanding,

Silona

 

 

 

On Fri, Jan 18, 2019 at 12:26 PM Vipin Bharathan <vipinsun@...> wrote:

Hi all,

 

Agree with Hart.

Considering that the year of the pig is fast upon us (Feb 5) we have to get organized on this very fast. Let us get a vote going on the tsc by email, including a debate if anyone has objections, but get back right away, instead of waiting for TSC meeting to engage.

1. The idea of a contributors summit is great. Where meaty topics can be discussed without much of a preamble. I assume that this will not be taking place in HK in March. Please clarify. There are always going to be issues of inclusion, make the gating factor a willingness to suggest/lead a discussion and rough topics for this-maybe

2.For a bootcamp, as Hart said, we need experts to show up to make this a success- this might be the most fundamental problem.

- Loosely define what a Hyperledger bootcamp expectations are:

  • we understand that the bootcamp's overall aim is to increase community engagement; but what is in it for the attendees? especially the newbies or someone who has never heard of this before? Should there be not some "meat" instead of being a general marketing and documentation session to attract people?
  • I would suggest hitting the core concepts in Blockchain and then relating that to our work in Hyperledger  as the "meat". 
  • level of suggested general expertise (who is expected to attend)
  • level of general blockchain expertise needed. Developers? Business peole? both?
  • Teaser on what the breakout sections are are
  •  What if any level of hands-on engagement there will be (no point in having endless downloading of multiple components; spending the majority of time on sysadmin type activities)-  
  • Who are the experts who will lead the breakout sessions.
  • Language barrier (translators, slides in chinese alongside english?)
  • The great firewall- what can get through there if there are web based content.
  • Suggest that there should be some boilerplate slides on Blockchain/Hyperledger/WG or project specif stuff to be optionally repeated per session.

I know that there are commitments from several groups for breakout sessions. Chiefly Ursa, Indy, Cello, Caliper etc.

I had proposed a list of breakouts, maybe some that I can lead, but as a tentative list for all, during each of these generic ones we can talk about what work is going on in each framework around that, also challenge people to propose topics.

  1. A session on IDWG 
  2. One on Arch WG.  (Explain the consensus and smart contract white paper)
  3. Privacy & confidentiality 
  4. Interoperability - a survey- Fabric network interoperability, others if any
  5. Regulations and the blockchain - business
  6. Digital Tokens in Blockchain and in Hyperledger - business and technical 
  7. A survey of cryptographic techniques (primitives, data structures, protocols, development challenges) in Hyperledger and Blockchain - relate to Ursa
  8. Smart contract generation and transformation 
  9. Iroha session
  10. Iroha use cases in Cambodia
  11. Other use cases (Monatago)- Find Chinese/other Asian use cases
  12. Fabric
  13. Sawtooth

Some of these may seem advanced; but you can dial it down to the concepts and relate to general blockchain and show how people can get involved in each .

 

Exposing people to the depth of the ecosystem and they will respond in a positive way. Why should they devote time to Hyperledger instead of Ethereum or public Corda or anything like that.

If you have read until here you are brave.

 

Consistent with the year of the pig; wish you all prosperity and wealth!

Best,

Vipin

 

On Thu, Jan 17, 2019 at 9:23 PM hmontgomery@... <hmontgomery@...> wrote:

Adding my 2c on some of this:

 

On splitting the onboarding from the maintainer meetings:  this is a great idea and I’m glad we’re doing it.  I think this is pretty noncontroversial, though.

 

On invite-only stuff:   +1 to Brian and Shawn.  I really dislike the idea of invite-only summits.  At minimum, if we invite N people, the (N + 1)th person is always going to be upset and feel a little undervalued, particularly if the criteria for invitation aren’t completely transparent and clear (what is a “valued contributor” anyway?  Why 22 lines of code?).  If we announce that “maintainer summits” are for experienced/expert people only, I doubt we’ll get a lot of extraneous people, particularly if we don’t market them.  Requiring advance registration and not doing any marketing would seem like it would be sufficient at this point to deter people from showing up.  Maybe the Linux kernel and the devs behind it are famous enough that people would crash the maintainer summit, but I highly doubt that we are.

 

If we really do want to restrict registration, then I would suggest we have some kind of lightweight application process.  Presumably this wouldn’t be much of a strain on the staff because most people could be approved without much thought.  This way we could include all “borderline” people—why filter out people that could possibly contribute and really want to be there—and maybe some experts that aren’t necessarily core contributors but want to be or who can help us out.  For instance, if some of the zcash cryptographers wanted to show up to help us work on zero knowledge stuff, we would definitely want them there, even if they aren’t core contributors.

 

On the boot camps:  my big question about this is how can we incentivize enough of the core people to attend these to make it worth the time of new people.  Tacking these on to otherwise big events (i.e. the global forum and the member summit) seems like a good thing to do, but probably we need more.  Chris brought up the example of the Beijing hackfest as an example of where we didn’t get enough experts, and I agreed with his point.  Quite frankly I’m a bit worried about the attendance for the Hong Kong event.  I was planning on coming since I have to make a trip in March to Japan anyway, but how many “hackfest regular experts” are?  We need to make sure we have enough “experts” that it is easy for new people to approach them.  Can we twist some arms to get people to show?

 

If you’ve made it this far, thanks for reading.  Hopefully this makes some minimal amount of sense.

 

Thanks,

Hart

 

 

 

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Thursday, January 17, 2019 9:59 AM
To: tsc@...
Subject: Re: [Hyperledger TSC] Hyperledger BootCamp in Hong Kong Mar 7,9 2019

 

To clarify a bit...

 

The HK BootCamp would still welcome any maintainer or other core contributor who can make it and help us mentor new devs into becoming deeper users and contributors. Given what seemed like low numbers of such core contributors for the March event in HK, but still substantial dev interest locally, the choice really was to reframe the HK event as a Bootcamp, or cancel it.  We assumed that going forward as a BootCamp would be better than to cancel, but testing that assumption with the TSC for a few days by email might have been better.  At this point, can we go forward with the HK BootCamp?

 

The second part of this is really a discussion about the "Core Contributor summit" part.  Let me make Tracy's articulation of the rationale she had for making it "invite-only" a bit more explicit, and reframe it as a choice, so the TSC can discuss further and be the one to decide, and we can implement for whenever such a summit will be held (no planned time or location yet).

 

The choice is:

 

A) Core Contributor Summits are invite-only.  Invites are sent to Maintainers and to contributors as defined below.  Invites may be extended (by other Core Contributors, perhaps?) beyond the defined list for someone with clear commitment to contribute.  Invitees are strongly urged to attend so meaningful work can be accomplished, and cross-project conversations can happen.  On the upside, this might allow participants to feel safer in discussing sensitive topics.  On the downside, it may exclude people who would otherwise want to come but don't know others well enough to be on anyone's list.

 

B) Core Contributor Summits are not limited by invite.  Maintainers and other core contributors are strongly urged to attend, so each project has a critical mass of those maintainers and meaningful work can be accomplished, and cross-project conversations can happen. But anyone is allowed to register and attend, and is expected not to slow down discussions if they aren't up to speed on the issues.

 

In either case, Chatham House rules would apply, which means that you can share outside the meeting what was said in the meeting, but not who said it, unless they give permission.  Notes will still be published as an official record, but will record the overall discussion and decisions.

 

Of these two, which do people on the TSC prefer?  Open to a third way if one occurs to someone.

 

A little while ago I suggested Tracy take a look at how Linux Kernel Summits are run.  To my surprise, those are invite-only.  Invite-only discussions are not my style, and I feel like we do fight against riannatural tendencies to have dev discussions on private forums rather than where they should be (Jira, email, rocketchat, etc).  But, IMHO this is something the TSC should discuss and decide, not HL staff.

 

Brian

 

 

On 1/17/19 9:19 AM, Tracy Kuhrt wrote:

Hi, Shawn.

 

The name of the summit may be a bad one. The current proposal has the following regarding the participants:

A short list of contributors will be created that includes:

·  TSC members

·  Working group chairs and vice chairs

·  Active Core Contributors - defined as contributors who have contributed 80% of the code and have made a contribution in the last 6 months (as of January 15th, using the project reports tool, this list included 54 people)   

In addition to the above, anyone that suggests a topic is added to the short list of names. 

 

The program committee will use this list to determine who should receive an invite.

 

The proposal was intended to keep these summits (call them Core Contributor Summits if you will) limited to a small set of people to ensure that progress can be made on advancing Hyperledger's technical community and source bases. The goal of these summits are:

to encourage cross collaboration amongst the different projects that are part of Hyperledger. This cross collaboration can come in the form of education about each of the projects, specific work surrounding an architectural component of the frameworks (e.g., common consensus mechanisms), contribution or review of cross-project whitepapers developed by the different working groups, or other items that the maintainers feel is important to ensuring that we are one community.

 

with the topics including:

·  items that enhance cross collaboration amongst projects

·  items that are easier to resolve in person than over email

·  "information sharing" topics if they are clearly of interest to the wider development community (i.e., advanced training in topics that would be useful to all projects)

 

From your email, I hope I have addressed the maintainer vs. contributor question with the above. The question that may still be open is whether these summits should be open to any contributor or limited (as is currently proposed). I chose "invite only" because I stole a lot of what you see in the document from the Linux Kernel Maintainers Summit, and I thought it made sense to have a small set of people who would be able to more easily sit down and make decisions and hack out solutions focused on the goals. Another consideration is whether an open meeting would allow people to feel safe expressing their point of view under a set of Chatham House rules.

 

I am completely open to feedback though, and I would appreciate any feedback that you can provide either on the mailing list or by providing comments directly on the wiki page. In no way should you consider my attempt at documenting the Maintainers Summits as anything other than a straw man for people to rip apart and put back together again.

 

Thanks for the initial thoughts, and I look forward to hearing more from you and others. 

 

----
Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...

Hyperledger Chat: @tkuhrt

 

 

On Thu, Jan 17, 2019 at 9:32 AM Shawn Amundson <amundson@...> wrote:

The 'Maintainers Summit' idea probably deserves more community discussion. The current proposal would exclude most of the community, with most of the community hearing later "we decided this a the thing you were excluded from". Changing it to a 'Contributors Summit', where it is open to anyone who has materially been involved in HL projects would be healthier from a community perspective.

 

-Shawn

 

On Wed, Jan 16, 2019 at 10:20 PM Silona Bonewald <sbonewald@...> wrote:

Howdy,

 

I wanted to explain in more depth about why Hackfests are being cancelled.  Instead they are being replaced by different events with different audiences.

 

We are doing a Bootcamp in HK for the time we reserved for the HK HackFest.  There was considerable feedback about how the Hackfests were being run.  We noticed two major trends.

 

One that we needed a space to onboard new community members and contributors.  Many projects needed to learn how to onboard and create friendlier environments for the volunteers. In China, we have many members but not as much participation across the projects,  We wanted to directly address that need.  The event also gives maintainers a chance to recruit and increase diversity.  

 

The second trend is that we needed to have some deep discussions on Hyperledger as a whole for the maintainers.  We needed to document and make decisions as a group.  There is some overlap in that some maintainers still need to attend bootcamps.

 

The first event is going to be a BootCamp.  https://wiki2.hyperledger.org/display/events/Bootcamps

The Bootcamp's purpose is first to help newcomers more easily engage in the community.  The second purpose is to also help the Maintainers receive valuable feedback on how better to engage the community.  There will also we some "intermediate" level breakouts taking place at the bootcamp as well it is a very fluid format.  For example, the Ursa team will be working with interested Chinese companies about not just working on but leading the Chinese Crypto libraries.  

 

We are working to standardized the bootcamps so that other organizations can also lead their own.  We are creating an approval and coaching process.  Currently, we are talking to the BC govt about a smaller Indy, Ursa bootcamp, a DefCon village about an Ursa one, and the Denver startup community on one for Indy.   The are purposely have breakout sessions with varied levels of experience needed.

Basic requirements are they must complete are

1) The basic logistical checklist so we know things are well run

2) Transparently plan the breakout groups so that the CA team knows that the projects, workgroups and labs will be well represented

3) I'm sure as we iterate we'll create more ;-)

 

The second type of event is the Maintainers Summit.  These summits will have different themes but are much higher level in focus.  They will only available to maintainers and not the general public unlike the bootcamps. They will be held Chatham house rules so that companies can more easily collaborate and negotiate.  The first summit will be focused on the overall architecture of Hyperledger especially interoperability.  We, the CA team, are going to be doing individual "Deep Dives" with certain identified Projects beforehand to get a feel for the structure.  Tracy has been hard at work on this section in the wiki https://wiki2.hyperledger.org/display/events/Maintainers+Summits

 

I hope this clarifies things.  Please feel free to ask us questions and/or add them to the wiki sections that are live and in progress.

 

Thank you!

Silona


--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf



--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org



--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


Re: Hyperledger BootCamp in Hong Kong Mar 7,9 2019

Silas Davis
 

Firstly sorry I missed last week's TSC - I hastily concluded it was cancelled but I was looking at a previous email.

I am glad to see the hackfests being shook up - there must be space for a good event in that slot, but I never managed to get much out of them other than meeting people.

Regarding the Maintainer's Summit (which definitely needs a rename if it not all maintainers are invitees) I'm very amenable to the goal of keeping down numbers and raising the signal-to-noise, but wary of the disenfranchisement it may cause for the N+1'th as Hart describes. The Linux Kernel does work this way but as my fellow Burrow maintainer Sean Young (and Linux IR system submaintainer) points out the Linux project has many other open access summits for filesystem and so on. I think we would want those who can make a useful architectural or technical contribution to be able to attend.

On the wiki we have:
> Active Core Contributors - defined as contributors who have contributed 80% of the code

This seems far too high a bar to me - basically one person per project (excluding those invited by their TSC membership or WG chairship). I would prefer something like the 'top 3 active maintainer/contributors' as agreed by the project as sufficient.

Would the following be workable (extending Brian's idea of invite-by-invitee):

Define a fairly limited group of root invitees (TSC + WG chairs + core maintainer/contributors). Give each person in that group 3 (or 2 or 4...) invites to use as they see fit - with the understanding that they should not invite people just because they have a ticket, but that because they are in a position to contribute and not slow things down, though this would be self-policed. To avoid the N+1 style problems we should allow further people to be invited through proposal to the TSC on a case-by-case basis. To help ameliorate cronyism (though I would expect people to know each other who work on the same project) it should be possible for people to self-propose their invitation to the summit through the TSC. The proposal process would be simple - just an email with who they are, why they are interested, what they can contribute, and what prior proof of engagement with a project or Hyperledger they have and the TSC can vote if necessary. On the demand side of the equation, I think it would be sufficient to not publicise outside of mailing lists and for the event itself simply not be of that much interest to those not engaged with the guts of the projects or Hyperledger.

Something like this might keep the event organic and non-exclusionary (even if it is by design not inclusionary) but keep it focussed.

Final half-baked thought: I am deeply dubious of introducing a credit score in Hyperledger for contribution, but on the topic of encouraging experts to attend bootcamps where the natural incentives may be a bit one-sided (or at least the business incentives). I'm aware that in other discussions we are sometimes reaching for metrics for the 'level of contribution' (such as who should be able to attend the Maintainer's Summit) so maybe there could be some recognition of those who are willing to put time in for the benefit of Hyperledger outside their immediate remit - e.g. through attending/running bootcamps - that could accrue some (non-compensatory) benefits - like the ability to invite people to other events, to stand for TSC or WG chair, etc. Perhaps this is a bad idea, I don't know.

Silas

On Mon, 21 Jan 2019 at 21:09, hmontgomery@... <hmontgomery@...> wrote:

Hi Silona,

 

Thanks for the email—and no need to apologize!  I think we’re headed in the right direction on this.  I think most people (myself included) were just a little surprised by the suddenness of this whole thing.  Of course, not having TSC meetings for a month and a half probably didn’t help things either.

 

Would it be possible to put up a  more  detailed tentative agenda in the near future?  My experience with hackfests has been that more people will show up (particularly from the core group) if there is something concrete on the agenda that they are interested in working on.  This might not be the easiest thing to do months in advance, but I think it helps drive attendance.  The more details we can put in the agenda, the better.

 

I think the current proposal for an agenda is probably too ambitious for a boot camp, and I would be very surprised if new people landed code commits (for reference, the only time I can remember total newbies landing commits was in the first six months of the project—maybe there have been others that I don’t know about).  Do we have good statistics on who is attending?  Based on historic data, I would be surprised if even half of the people attending came ready to code and, for most of those who are ready to code, just setting up and using the projects/platforms is all they really want to do.  I’m sure there will be some exceptions (I’m really hoping some Ursa people are an exception here), but I think this is something that we should probably plan to think about.

 

I think it would be a great idea if we could gather really detailed statistics from this event.  How many people (actually) showed up?  How many people came with a dev environment on their laptop?  How many actually set up a project?  How many attempted some coding?  Who (if anyone) landed PRs?  What platforms did they use?  Did anyone set up multiple platforms?  This would hopefully allow us to tailor these events more in the future, even if we had to approximate these and do some counting by hand. 

 

Before I ramble even further, thanks again for tinkering with the hackfest structure and moving it forward.  We’ve literally had the exact same discussion probably ten times over the past few years about how we can improve hackfests, and we haven’t changed much of anything, so shaking up things seems to be the right move.  I hope that we can iterate and get to something that makes everyone happy.

 

Thanks,

Hart

 

From: Silona Bonewald [mailto:sbonewald@...]
Sent: Saturday, January 19, 2019 6:38 PM
To: Vipin Bharathan <vipinsun@...>
Cc: Montgomery, Hart <hmontgomery@...>; Brian Behlendorf <bbehlendorf@...>; tsc@...
Subject: Re: [Hyperledger TSC] Hyperledger BootCamp in Hong Kong Mar 7,9 2019

 

 

This is a Mea Culpa email.   Ignorance isn't an excuse but I did want to explain the thinking behind what happened.  It's my mistake and I'm sorry for the confusion I caused by not keeping everyone informed.  Going forward, I'm gonna be sending a lot more little emails to this group.

 

I viewed the new Maintainers/Contributors Summit as the actual HackFest replacement TSC attendance wise.  A Summit is more of an "All Hands on Deck" type of an event.  I felt like I was postponing the "HackFest" pending reworking into a summit/think tank style structure.  I asked Tracy to very quickly post a proposal to the wiki so that we could start discussing it as a community and we could discuss it at the TSC meeting.

 

I did not view the bootcamp as a replacement other than - we still needed to take advantage of the timing and free space Julian obtained for us.  My decision was primarily driven by the fact we didn't feel like we could organize a complete and effective HackFest in time.  We did not have a date or location until a week ago.  The location opened up and we had to jump on it FAST!  So I compromised.  This did cause some confusion hence Ry saying "HackFest is cancelled" even though we closed the contract with the venue at the same time for a bootcamp.   The real answer is a good deal more complex than that...

 

I received primarily negative feedback about the current state of the HackFests during HGF.  My team and Julian had a deep conversation about what we thought the APAC market would need in an event.  We discussed the chicken and egg problem of how hard it is for most maintainers to travel to APAC but not really having enough local maintainers to really make a HackFest work on a short notice.  Julian said one of his main issues was getting people from the over 50 APAC member companies on-boarded and participating in the community.  I suggested taking advantage of the free space he had just found with doing a bootcamp instead of a HackFest.  It would be our first bootcamp.  It might be a little rough but better than not having an event.

 

This would give us time to work on reframing the HackFest into an event that has a few clearly defined deliverables like a Summit/Think Tank. 

 

We were already designing a generalized bootcamp formula.  My CA team realized we needed a recruiting/onboarding style event to be done regularly and distributed for our contributors and potential contributors.  We wanted more on-boarding style events to take place this year.  But we wanted a safer structure than the hackathons.  We started planning on-boarding events in India, S America and maybe Singapore for this year. 

 

The Indy and Ursa projects liked the idea of training bootcamps so much they asked if they could do a "one off" version.  Since my team was already talking about how to standardize it.  I decided to work with them on theirs.  We are discussing what the future approval process will be.  I felt safe working with these two teams because both projects did similar 4hr formats at the HGF.  We wanted to iterate on it and make it stronger!  So I viewed bootcamps as something new.  I did not see them as a HackFest replacement attendance wise.  I saw the bootcamps as a way for getting measurable participation and overcoming that scary "First edit" or "first Commit" and the thrill of the first acceptance.  I also saw it as a way for our maintainers to see first hand the affects they have on the newbies. Those people will go on to participate more and the maintainers can take a clearer mentorship role.

 

A bootcamp doesn't require the complete coverage of all HL's maintainers.  There could be many bootcamps.  Bootcamps have an inclusive model so people can self organize based on the resources available.  I view them as merger of a codeathon/unconference/training session.  The key takeaway from a codeathon is the wiki pre-planning. So for the bootcamps we will pre-planning the breakout sessions. Like an unconference, the attendees decide what those breakout sessions will be.  And we will as a team, target people ready and willing to onboard new people.   There is much flexibility built in regards to the scheduling on the breakouts.  So as Brian says, if a bunch arrives and decides to do a hard core session, they can.  The sign up spreadsheet for the Breakouts will indicate things like Level, Language, prereq, software needed, etc.

 

For this bootcamp in HK,  I am talking with Indy, Ursa, Cello, Caliper, the China Tech WG, and others about possible sessions.  They will each get planning pages on the wiki as we move forward.  We will be figuring out things like, size, timing, and placement of those sessions.  Dorothy and I have been talking with Marketing to see all the general materials cranked out by Tuesday.   She and I are also working with Events to nail down logistics and get registration ready by Tuesday. 

 

It is a BIG lift for the LF team to make this deadline.  Maybe I should have said "No" and decided to wait until April/May for a different event in APAC and possibly it could have been a summit.  But I wanted to do something in March even if it is a smaller event.  I really wanted to start iterating on it and taking advantage of the location and timing.  I may be over confident but I have run similar but much larger events in the past, so I think we can do it.

 

We have an EXTREMELY short window to get marketing and registration done before Feb 4th (which is really Jan 28th.)  Registration and marketing starts on the 22nd.  But after that, we focus on mentoring people on creating the breakout sessions.  These sessions are where my team will need the most help from the TSC in regards to recruiting. 

 

Having run several hardware startups, I am properly terrified of Chinese New Year.  It's hard to explain how thoroughly things shut down... even a couple of weeks advance becomes CRUNCH time.  Getting the possible attendee's attention in the next week and half is going to be a very heavy lift for Julian and his team.  I was distracted by all the logistics I had to get in focus quickly. So I did not inform the TSC.  I was also a bit to focused on getting very basic documentation up on the wiki before sending an email explaining the situation. But it is up and we are live editing it!  I hope it will be more polished by Tuesday!  https://wiki2.hyperledger.org/display/events/Hyperledger+BootCamp+-+Hong+Kong

 

As to Vipin's checklist,  these are all things we have been discussing organizationally for the bootcamps!   I will ask that for those discussions on the bootcamps that we have them publicly on the wiki.  You can do inline comments!  Right now I have the other members outside of HL staff that will be running bootcamps asking similar questions.  I don't want to lose these ideas esp the possible sessions. I would like them to be findable by the participant and organizers.  We might not be able to implement all of the ideas at each Bootcamp.   But they are inspiring to the person wanting to do a breakout session at the NEXT one!  I for one am very interested in posting re-usable training materials.  I believe Indy is already on it and will be sharing theirs so we can post links to them once created.

 

Also Hart - you are 100% right about tying the bootcamps to other events to help with maintainers' budget.  There is a big blockchain event in HK at the same time as this bootcamp on Mar 7th, 8th.  Julian is hoping to use it to his advantage :-)  If you are attending this conference in HK - we will ask you about leading a session!  The one-off bootcamps are also tied to events such as a BC govt event, Denver startup event w 18K people, and DefCon.  I used to do all my similar style events at SXSW and I always had a very full house :-)

 

I hope the site will be live on Tuesday and when it is - I will post it here to the list so we can all help promote it.

 

As for the postponed HackFest/Summit,  I'm glad to see the discussion here on the mailing list. 

 

Thank you for understanding,

Silona

 

 

 

On Fri, Jan 18, 2019 at 12:26 PM Vipin Bharathan <vipinsun@...> wrote:

Hi all,

 

Agree with Hart.

Considering that the year of the pig is fast upon us (Feb 5) we have to get organized on this very fast. Let us get a vote going on the tsc by email, including a debate if anyone has objections, but get back right away, instead of waiting for TSC meeting to engage.

1. The idea of a contributors summit is great. Where meaty topics can be discussed without much of a preamble. I assume that this will not be taking place in HK in March. Please clarify. There are always going to be issues of inclusion, make the gating factor a willingness to suggest/lead a discussion and rough topics for this-maybe

2.For a bootcamp, as Hart said, we need experts to show up to make this a success- this might be the most fundamental problem.

- Loosely define what a Hyperledger bootcamp expectations are:

  • we understand that the bootcamp's overall aim is to increase community engagement; but what is in it for the attendees? especially the newbies or someone who has never heard of this before? Should there be not some "meat" instead of being a general marketing and documentation session to attract people?
  • I would suggest hitting the core concepts in Blockchain and then relating that to our work in Hyperledger  as the "meat". 
  • level of suggested general expertise (who is expected to attend)
  • level of general blockchain expertise needed. Developers? Business peole? both?
  • Teaser on what the breakout sections are are
  •  What if any level of hands-on engagement there will be (no point in having endless downloading of multiple components; spending the majority of time on sysadmin type activities)-  
  • Who are the experts who will lead the breakout sessions.
  • Language barrier (translators, slides in chinese alongside english?)
  • The great firewall- what can get through there if there are web based content.
  • Suggest that there should be some boilerplate slides on Blockchain/Hyperledger/WG or project specif stuff to be optionally repeated per session.

I know that there are commitments from several groups for breakout sessions. Chiefly Ursa, Indy, Cello, Caliper etc.

I had proposed a list of breakouts, maybe some that I can lead, but as a tentative list for all, during each of these generic ones we can talk about what work is going on in each framework around that, also challenge people to propose topics.

  1. A session on IDWG 
  2. One on Arch WG.  (Explain the consensus and smart contract white paper)
  3. Privacy & confidentiality 
  4. Interoperability - a survey- Fabric network interoperability, others if any
  5. Regulations and the blockchain - business
  6. Digital Tokens in Blockchain and in Hyperledger - business and technical 
  7. A survey of cryptographic techniques (primitives, data structures, protocols, development challenges) in Hyperledger and Blockchain - relate to Ursa
  8. Smart contract generation and transformation 
  9. Iroha session
  10. Iroha use cases in Cambodia
  11. Other use cases (Monatago)- Find Chinese/other Asian use cases
  12. Fabric
  13. Sawtooth

Some of these may seem advanced; but you can dial it down to the concepts and relate to general blockchain and show how people can get involved in each .

 

Exposing people to the depth of the ecosystem and they will respond in a positive way. Why should they devote time to Hyperledger instead of Ethereum or public Corda or anything like that.

If you have read until here you are brave.

 

Consistent with the year of the pig; wish you all prosperity and wealth!

Best,

Vipin

 

On Thu, Jan 17, 2019 at 9:23 PM hmontgomery@... <hmontgomery@...> wrote:

Adding my 2c on some of this:

 

On splitting the onboarding from the maintainer meetings:  this is a great idea and I’m glad we’re doing it.  I think this is pretty noncontroversial, though.

 

On invite-only stuff:   +1 to Brian and Shawn.  I really dislike the idea of invite-only summits.  At minimum, if we invite N people, the (N + 1)th person is always going to be upset and feel a little undervalued, particularly if the criteria for invitation aren’t completely transparent and clear (what is a “valued contributor” anyway?  Why 22 lines of code?).  If we announce that “maintainer summits” are for experienced/expert people only, I doubt we’ll get a lot of extraneous people, particularly if we don’t market them.  Requiring advance registration and not doing any marketing would seem like it would be sufficient at this point to deter people from showing up.  Maybe the Linux kernel and the devs behind it are famous enough that people would crash the maintainer summit, but I highly doubt that we are.

 

If we really do want to restrict registration, then I would suggest we have some kind of lightweight application process.  Presumably this wouldn’t be much of a strain on the staff because most people could be approved without much thought.  This way we could include all “borderline” people—why filter out people that could possibly contribute and really want to be there—and maybe some experts that aren’t necessarily core contributors but want to be or who can help us out.  For instance, if some of the zcash cryptographers wanted to show up to help us work on zero knowledge stuff, we would definitely want them there, even if they aren’t core contributors.

 

On the boot camps:  my big question about this is how can we incentivize enough of the core people to attend these to make it worth the time of new people.  Tacking these on to otherwise big events (i.e. the global forum and the member summit) seems like a good thing to do, but probably we need more.  Chris brought up the example of the Beijing hackfest as an example of where we didn’t get enough experts, and I agreed with his point.  Quite frankly I’m a bit worried about the attendance for the Hong Kong event.  I was planning on coming since I have to make a trip in March to Japan anyway, but how many “hackfest regular experts” are?  We need to make sure we have enough “experts” that it is easy for new people to approach them.  Can we twist some arms to get people to show?

 

If you’ve made it this far, thanks for reading.  Hopefully this makes some minimal amount of sense.

 

Thanks,

Hart

 

 

 

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Thursday, January 17, 2019 9:59 AM
To: tsc@...
Subject: Re: [Hyperledger TSC] Hyperledger BootCamp in Hong Kong Mar 7,9 2019

 

To clarify a bit...

 

The HK BootCamp would still welcome any maintainer or other core contributor who can make it and help us mentor new devs into becoming deeper users and contributors. Given what seemed like low numbers of such core contributors for the March event in HK, but still substantial dev interest locally, the choice really was to reframe the HK event as a Bootcamp, or cancel it.  We assumed that going forward as a BootCamp would be better than to cancel, but testing that assumption with the TSC for a few days by email might have been better.  At this point, can we go forward with the HK BootCamp?

 

The second part of this is really a discussion about the "Core Contributor summit" part.  Let me make Tracy's articulation of the rationale she had for making it "invite-only" a bit more explicit, and reframe it as a choice, so the TSC can discuss further and be the one to decide, and we can implement for whenever such a summit will be held (no planned time or location yet).

 

The choice is:

 

A) Core Contributor Summits are invite-only.  Invites are sent to Maintainers and to contributors as defined below.  Invites may be extended (by other Core Contributors, perhaps?) beyond the defined list for someone with clear commitment to contribute.  Invitees are strongly urged to attend so meaningful work can be accomplished, and cross-project conversations can happen.  On the upside, this might allow participants to feel safer in discussing sensitive topics.  On the downside, it may exclude people who would otherwise want to come but don't know others well enough to be on anyone's list.

 

B) Core Contributor Summits are not limited by invite.  Maintainers and other core contributors are strongly urged to attend, so each project has a critical mass of those maintainers and meaningful work can be accomplished, and cross-project conversations can happen. But anyone is allowed to register and attend, and is expected not to slow down discussions if they aren't up to speed on the issues.

 

In either case, Chatham House rules would apply, which means that you can share outside the meeting what was said in the meeting, but not who said it, unless they give permission.  Notes will still be published as an official record, but will record the overall discussion and decisions.

 

Of these two, which do people on the TSC prefer?  Open to a third way if one occurs to someone.

 

A little while ago I suggested Tracy take a look at how Linux Kernel Summits are run.  To my surprise, those are invite-only.  Invite-only discussions are not my style, and I feel like we do fight against riannatural tendencies to have dev discussions on private forums rather than where they should be (Jira, email, rocketchat, etc).  But, IMHO this is something the TSC should discuss and decide, not HL staff.

 

Brian

 

 

On 1/17/19 9:19 AM, Tracy Kuhrt wrote:

Hi, Shawn.

 

The name of the summit may be a bad one. The current proposal has the following regarding the participants:

A short list of contributors will be created that includes:

·  TSC members

·  Working group chairs and vice chairs

·  Active Core Contributors - defined as contributors who have contributed 80% of the code and have made a contribution in the last 6 months (as of January 15th, using the project reports tool, this list included 54 people)   

In addition to the above, anyone that suggests a topic is added to the short list of names. 

 

The program committee will use this list to determine who should receive an invite.

 

The proposal was intended to keep these summits (call them Core Contributor Summits if you will) limited to a small set of people to ensure that progress can be made on advancing Hyperledger's technical community and source bases. The goal of these summits are:

to encourage cross collaboration amongst the different projects that are part of Hyperledger. This cross collaboration can come in the form of education about each of the projects, specific work surrounding an architectural component of the frameworks (e.g., common consensus mechanisms), contribution or review of cross-project whitepapers developed by the different working groups, or other items that the maintainers feel is important to ensuring that we are one community.

 

with the topics including:

·  items that enhance cross collaboration amongst projects

·  items that are easier to resolve in person than over email

·  "information sharing" topics if they are clearly of interest to the wider development community (i.e., advanced training in topics that would be useful to all projects)

 

From your email, I hope I have addressed the maintainer vs. contributor question with the above. The question that may still be open is whether these summits should be open to any contributor or limited (as is currently proposed). I chose "invite only" because I stole a lot of what you see in the document from the Linux Kernel Maintainers Summit, and I thought it made sense to have a small set of people who would be able to more easily sit down and make decisions and hack out solutions focused on the goals. Another consideration is whether an open meeting would allow people to feel safe expressing their point of view under a set of Chatham House rules.

 

I am completely open to feedback though, and I would appreciate any feedback that you can provide either on the mailing list or by providing comments directly on the wiki page. In no way should you consider my attempt at documenting the Maintainers Summits as anything other than a straw man for people to rip apart and put back together again.

 

Thanks for the initial thoughts, and I look forward to hearing more from you and others. 

 

----
Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...

Hyperledger Chat: @tkuhrt

 

 

On Thu, Jan 17, 2019 at 9:32 AM Shawn Amundson <amundson@...> wrote:

The 'Maintainers Summit' idea probably deserves more community discussion. The current proposal would exclude most of the community, with most of the community hearing later "we decided this a the thing you were excluded from". Changing it to a 'Contributors Summit', where it is open to anyone who has materially been involved in HL projects would be healthier from a community perspective.

 

-Shawn

 

On Wed, Jan 16, 2019 at 10:20 PM Silona Bonewald <sbonewald@...> wrote:

Howdy,

 

I wanted to explain in more depth about why Hackfests are being cancelled.  Instead they are being replaced by different events with different audiences.

 

We are doing a Bootcamp in HK for the time we reserved for the HK HackFest.  There was considerable feedback about how the Hackfests were being run.  We noticed two major trends.

 

One that we needed a space to onboard new community members and contributors.  Many projects needed to learn how to onboard and create friendlier environments for the volunteers. In China, we have many members but not as much participation across the projects,  We wanted to directly address that need.  The event also gives maintainers a chance to recruit and increase diversity.  

 

The second trend is that we needed to have some deep discussions on Hyperledger as a whole for the maintainers.  We needed to document and make decisions as a group.  There is some overlap in that some maintainers still need to attend bootcamps.

 

The first event is going to be a BootCamp.  https://wiki2.hyperledger.org/display/events/Bootcamps

The Bootcamp's purpose is first to help newcomers more easily engage in the community.  The second purpose is to also help the Maintainers receive valuable feedback on how better to engage the community.  There will also we some "intermediate" level breakouts taking place at the bootcamp as well it is a very fluid format.  For example, the Ursa team will be working with interested Chinese companies about not just working on but leading the Chinese Crypto libraries.  

 

We are working to standardized the bootcamps so that other organizations can also lead their own.  We are creating an approval and coaching process.  Currently, we are talking to the BC govt about a smaller Indy, Ursa bootcamp, a DefCon village about an Ursa one, and the Denver startup community on one for Indy.   The are purposely have breakout sessions with varied levels of experience needed.

Basic requirements are they must complete are

1) The basic logistical checklist so we know things are well run

2) Transparently plan the breakout groups so that the CA team knows that the projects, workgroups and labs will be well represented

3) I'm sure as we iterate we'll create more ;-)

 

The second type of event is the Maintainers Summit.  These summits will have different themes but are much higher level in focus.  They will only available to maintainers and not the general public unlike the bootcamps. They will be held Chatham house rules so that companies can more easily collaborate and negotiate.  The first summit will be focused on the overall architecture of Hyperledger especially interoperability.  We, the CA team, are going to be doing individual "Deep Dives" with certain identified Projects beforehand to get a feel for the structure.  Tracy has been hard at work on this section in the wiki https://wiki2.hyperledger.org/display/events/Maintainers+Summits

 

I hope this clarifies things.  Please feel free to ask us questions and/or add them to the wiki sections that are live and in progress.

 

Thank you!

Silona


--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf



--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org


Hyperledger Iroha Quarterly Update Due #tsc-project-update - Thu, 01/24/2019 #tsc-project-update #cal-reminder

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

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

When:
Thursday, 24 January 2019

Organizer:
tkuhrt@...

Description:
The Hyperledger Iroha update to the TSC was due January 21, 2019, and it will be presented to the TSC on January 24, 2019. Please review prior to the meeting and bring your questions.

View Event


Hyperledger Identity WG Quarterly Update Due #tsc-wg-update - Thu, 01/24/2019 #tsc-wg-update #cal-reminder

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

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

When:
Thursday, 24 January 2019

Organizer:
tkuhrt@...

Description:
The Hyperledger Identity WG update to the TSC was due January 21, 2019, and it will be presented to the TSC on January 24, 2019. Please review prior to the meeting and bring your questions.

View Event


Re: [Hyperledger Identity WG] Identity Working Group update for Q1-2019

bill
 

Well said Vipin and a very nice update…on time even!  See you on the next IDWG call.  Cheers!

 

From: tsc@... [mailto:tsc@...] On Behalf Of Vipin Bharathan
Sent: Monday, January 21, 2019 2:53 PM
To: Mark Wagner <mwagner@...>
Cc: Hyperledger List <tsc@...>; Identity-WG@...; architecture-wg@...
Subject: Re: [Hyperledger TSC] [Hyperledger Identity WG] Identity Working Group update for Q1-2019

 

Hello Mark,

 

The papers are meant to complement each other. Since the Arch WG paper is meant to deal with System Identities which are the identities that control the nodes and our paper with Identities in general.and transactor/user/IoT Identities in particular. Also the Identity WG paper is much larger in scope.

 

We already had a discussion about this and decided that the papers should stay as they are for now. When the ID WG paper comes out we might present a combined paper later.

 

Best,

Vipin  

 

On Mon, Jan 21, 2019 at 3:43 PM Mark Wagner <mwagner@...> wrote:

 

Vipin

 

Thanks for the writeup. It was on time and on target for me.

 

I like the idea of having someone who greets and assimilates the new folks. I am curious to see how that works and if it can be a blueprint for other efforts within the broader community.

 

A few questions on the papers:

How similar are the papers, do they "compete/conflict" or "compliment" each other ?

 

do you feel that the TSC should have a discussion on the two different WGs producing Identity papers ?

 

thanks

 

-mark

 

On Sun, Jan 20, 2019 at 11:43 AM Vipin Bharathan <vipinsun@...> wrote:

Hi TSC members & HL Community,

 

Please review and let me know if you have questions or comments before the next TSC meeting of 01/25/2019. I have already sent this out to the IDWG list seeking comments and additions.

 

Advance engagement will help us to get the maximum out of the next TSC meeting where several items are up for discussion. I will also try to port this to new confluence website before our meeting.

 

Thanks,

Vipin 



--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc


Re: Hyperledger BootCamp in Hong Kong Mar 7,9 2019

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

Hi Silona,

 

Thanks for the email—and no need to apologize!  I think we’re headed in the right direction on this.  I think most people (myself included) were just a little surprised by the suddenness of this whole thing.  Of course, not having TSC meetings for a month and a half probably didn’t help things either.

 

Would it be possible to put up a  more  detailed tentative agenda in the near future?  My experience with hackfests has been that more people will show up (particularly from the core group) if there is something concrete on the agenda that they are interested in working on.  This might not be the easiest thing to do months in advance, but I think it helps drive attendance.  The more details we can put in the agenda, the better.

 

I think the current proposal for an agenda is probably too ambitious for a boot camp, and I would be very surprised if new people landed code commits (for reference, the only time I can remember total newbies landing commits was in the first six months of the project—maybe there have been others that I don’t know about).  Do we have good statistics on who is attending?  Based on historic data, I would be surprised if even half of the people attending came ready to code and, for most of those who are ready to code, just setting up and using the projects/platforms is all they really want to do.  I’m sure there will be some exceptions (I’m really hoping some Ursa people are an exception here), but I think this is something that we should probably plan to think about.

 

I think it would be a great idea if we could gather really detailed statistics from this event.  How many people (actually) showed up?  How many people came with a dev environment on their laptop?  How many actually set up a project?  How many attempted some coding?  Who (if anyone) landed PRs?  What platforms did they use?  Did anyone set up multiple platforms?  This would hopefully allow us to tailor these events more in the future, even if we had to approximate these and do some counting by hand. 

 

Before I ramble even further, thanks again for tinkering with the hackfest structure and moving it forward.  We’ve literally had the exact same discussion probably ten times over the past few years about how we can improve hackfests, and we haven’t changed much of anything, so shaking up things seems to be the right move.  I hope that we can iterate and get to something that makes everyone happy.

 

Thanks,

Hart

 

From: Silona Bonewald [mailto:sbonewald@...]
Sent: Saturday, January 19, 2019 6:38 PM
To: Vipin Bharathan <vipinsun@...>
Cc: Montgomery, Hart <hmontgomery@...>; Brian Behlendorf <bbehlendorf@...>; tsc@...
Subject: Re: [Hyperledger TSC] Hyperledger BootCamp in Hong Kong Mar 7,9 2019

 

 

This is a Mea Culpa email.   Ignorance isn't an excuse but I did want to explain the thinking behind what happened.  It's my mistake and I'm sorry for the confusion I caused by not keeping everyone informed.  Going forward, I'm gonna be sending a lot more little emails to this group.

 

I viewed the new Maintainers/Contributors Summit as the actual HackFest replacement TSC attendance wise.  A Summit is more of an "All Hands on Deck" type of an event.  I felt like I was postponing the "HackFest" pending reworking into a summit/think tank style structure.  I asked Tracy to very quickly post a proposal to the wiki so that we could start discussing it as a community and we could discuss it at the TSC meeting.

 

I did not view the bootcamp as a replacement other than - we still needed to take advantage of the timing and free space Julian obtained for us.  My decision was primarily driven by the fact we didn't feel like we could organize a complete and effective HackFest in time.  We did not have a date or location until a week ago.  The location opened up and we had to jump on it FAST!  So I compromised.  This did cause some confusion hence Ry saying "HackFest is cancelled" even though we closed the contract with the venue at the same time for a bootcamp.   The real answer is a good deal more complex than that...

 

I received primarily negative feedback about the current state of the HackFests during HGF.  My team and Julian had a deep conversation about what we thought the APAC market would need in an event.  We discussed the chicken and egg problem of how hard it is for most maintainers to travel to APAC but not really having enough local maintainers to really make a HackFest work on a short notice.  Julian said one of his main issues was getting people from the over 50 APAC member companies on-boarded and participating in the community.  I suggested taking advantage of the free space he had just found with doing a bootcamp instead of a HackFest.  It would be our first bootcamp.  It might be a little rough but better than not having an event.

 

This would give us time to work on reframing the HackFest into an event that has a few clearly defined deliverables like a Summit/Think Tank. 

 

We were already designing a generalized bootcamp formula.  My CA team realized we needed a recruiting/onboarding style event to be done regularly and distributed for our contributors and potential contributors.  We wanted more on-boarding style events to take place this year.  But we wanted a safer structure than the hackathons.  We started planning on-boarding events in India, S America and maybe Singapore for this year. 

 

The Indy and Ursa projects liked the idea of training bootcamps so much they asked if they could do a "one off" version.  Since my team was already talking about how to standardize it.  I decided to work with them on theirs.  We are discussing what the future approval process will be.  I felt safe working with these two teams because both projects did similar 4hr formats at the HGF.  We wanted to iterate on it and make it stronger!  So I viewed bootcamps as something new.  I did not see them as a HackFest replacement attendance wise.  I saw the bootcamps as a way for getting measurable participation and overcoming that scary "First edit" or "first Commit" and the thrill of the first acceptance.  I also saw it as a way for our maintainers to see first hand the affects they have on the newbies. Those people will go on to participate more and the maintainers can take a clearer mentorship role.

 

A bootcamp doesn't require the complete coverage of all HL's maintainers.  There could be many bootcamps.  Bootcamps have an inclusive model so people can self organize based on the resources available.  I view them as merger of a codeathon/unconference/training session.  The key takeaway from a codeathon is the wiki pre-planning. So for the bootcamps we will pre-planning the breakout sessions. Like an unconference, the attendees decide what those breakout sessions will be.  And we will as a team, target people ready and willing to onboard new people.   There is much flexibility built in regards to the scheduling on the breakouts.  So as Brian says, if a bunch arrives and decides to do a hard core session, they can.  The sign up spreadsheet for the Breakouts will indicate things like Level, Language, prereq, software needed, etc.

 

For this bootcamp in HK,  I am talking with Indy, Ursa, Cello, Caliper, the China Tech WG, and others about possible sessions.  They will each get planning pages on the wiki as we move forward.  We will be figuring out things like, size, timing, and placement of those sessions.  Dorothy and I have been talking with Marketing to see all the general materials cranked out by Tuesday.   She and I are also working with Events to nail down logistics and get registration ready by Tuesday. 

 

It is a BIG lift for the LF team to make this deadline.  Maybe I should have said "No" and decided to wait until April/May for a different event in APAC and possibly it could have been a summit.  But I wanted to do something in March even if it is a smaller event.  I really wanted to start iterating on it and taking advantage of the location and timing.  I may be over confident but I have run similar but much larger events in the past, so I think we can do it.

 

We have an EXTREMELY short window to get marketing and registration done before Feb 4th (which is really Jan 28th.)  Registration and marketing starts on the 22nd.  But after that, we focus on mentoring people on creating the breakout sessions.  These sessions are where my team will need the most help from the TSC in regards to recruiting. 

 

Having run several hardware startups, I am properly terrified of Chinese New Year.  It's hard to explain how thoroughly things shut down... even a couple of weeks advance becomes CRUNCH time.  Getting the possible attendee's attention in the next week and half is going to be a very heavy lift for Julian and his team.  I was distracted by all the logistics I had to get in focus quickly. So I did not inform the TSC.  I was also a bit to focused on getting very basic documentation up on the wiki before sending an email explaining the situation. But it is up and we are live editing it!  I hope it will be more polished by Tuesday!  https://wiki2.hyperledger.org/display/events/Hyperledger+BootCamp+-+Hong+Kong

 

As to Vipin's checklist,  these are all things we have been discussing organizationally for the bootcamps!   I will ask that for those discussions on the bootcamps that we have them publicly on the wiki.  You can do inline comments!  Right now I have the other members outside of HL staff that will be running bootcamps asking similar questions.  I don't want to lose these ideas esp the possible sessions. I would like them to be findable by the participant and organizers.  We might not be able to implement all of the ideas at each Bootcamp.   But they are inspiring to the person wanting to do a breakout session at the NEXT one!  I for one am very interested in posting re-usable training materials.  I believe Indy is already on it and will be sharing theirs so we can post links to them once created.

 

Also Hart - you are 100% right about tying the bootcamps to other events to help with maintainers' budget.  There is a big blockchain event in HK at the same time as this bootcamp on Mar 7th, 8th.  Julian is hoping to use it to his advantage :-)  If you are attending this conference in HK - we will ask you about leading a session!  The one-off bootcamps are also tied to events such as a BC govt event, Denver startup event w 18K people, and DefCon.  I used to do all my similar style events at SXSW and I always had a very full house :-)

 

I hope the site will be live on Tuesday and when it is - I will post it here to the list so we can all help promote it.

 

As for the postponed HackFest/Summit,  I'm glad to see the discussion here on the mailing list. 

 

Thank you for understanding,

Silona

 

 

 

On Fri, Jan 18, 2019 at 12:26 PM Vipin Bharathan <vipinsun@...> wrote:

Hi all,

 

Agree with Hart.

Considering that the year of the pig is fast upon us (Feb 5) we have to get organized on this very fast. Let us get a vote going on the tsc by email, including a debate if anyone has objections, but get back right away, instead of waiting for TSC meeting to engage.

1. The idea of a contributors summit is great. Where meaty topics can be discussed without much of a preamble. I assume that this will not be taking place in HK in March. Please clarify. There are always going to be issues of inclusion, make the gating factor a willingness to suggest/lead a discussion and rough topics for this-maybe

2.For a bootcamp, as Hart said, we need experts to show up to make this a success- this might be the most fundamental problem.

- Loosely define what a Hyperledger bootcamp expectations are:

  • we understand that the bootcamp's overall aim is to increase community engagement; but what is in it for the attendees? especially the newbies or someone who has never heard of this before? Should there be not some "meat" instead of being a general marketing and documentation session to attract people?
  • I would suggest hitting the core concepts in Blockchain and then relating that to our work in Hyperledger  as the "meat". 
  • level of suggested general expertise (who is expected to attend)
  • level of general blockchain expertise needed. Developers? Business peole? both?
  • Teaser on what the breakout sections are are
  •  What if any level of hands-on engagement there will be (no point in having endless downloading of multiple components; spending the majority of time on sysadmin type activities)-  
  • Who are the experts who will lead the breakout sessions.
  • Language barrier (translators, slides in chinese alongside english?)
  • The great firewall- what can get through there if there are web based content.
  • Suggest that there should be some boilerplate slides on Blockchain/Hyperledger/WG or project specif stuff to be optionally repeated per session.

I know that there are commitments from several groups for breakout sessions. Chiefly Ursa, Indy, Cello, Caliper etc.

I had proposed a list of breakouts, maybe some that I can lead, but as a tentative list for all, during each of these generic ones we can talk about what work is going on in each framework around that, also challenge people to propose topics.

  1. A session on IDWG 
  2. One on Arch WG.  (Explain the consensus and smart contract white paper)
  3. Privacy & confidentiality 
  4. Interoperability - a survey- Fabric network interoperability, others if any
  5. Regulations and the blockchain - business
  6. Digital Tokens in Blockchain and in Hyperledger - business and technical 
  7. A survey of cryptographic techniques (primitives, data structures, protocols, development challenges) in Hyperledger and Blockchain - relate to Ursa
  8. Smart contract generation and transformation 
  9. Iroha session
  10. Iroha use cases in Cambodia
  11. Other use cases (Monatago)- Find Chinese/other Asian use cases
  12. Fabric
  13. Sawtooth

Some of these may seem advanced; but you can dial it down to the concepts and relate to general blockchain and show how people can get involved in each .

 

Exposing people to the depth of the ecosystem and they will respond in a positive way. Why should they devote time to Hyperledger instead of Ethereum or public Corda or anything like that.

If you have read until here you are brave.

 

Consistent with the year of the pig; wish you all prosperity and wealth!

Best,

Vipin

 

On Thu, Jan 17, 2019 at 9:23 PM hmontgomery@... <hmontgomery@...> wrote:

Adding my 2c on some of this:

 

On splitting the onboarding from the maintainer meetings:  this is a great idea and I’m glad we’re doing it.  I think this is pretty noncontroversial, though.

 

On invite-only stuff:   +1 to Brian and Shawn.  I really dislike the idea of invite-only summits.  At minimum, if we invite N people, the (N + 1)th person is always going to be upset and feel a little undervalued, particularly if the criteria for invitation aren’t completely transparent and clear (what is a “valued contributor” anyway?  Why 22 lines of code?).  If we announce that “maintainer summits” are for experienced/expert people only, I doubt we’ll get a lot of extraneous people, particularly if we don’t market them.  Requiring advance registration and not doing any marketing would seem like it would be sufficient at this point to deter people from showing up.  Maybe the Linux kernel and the devs behind it are famous enough that people would crash the maintainer summit, but I highly doubt that we are.

 

If we really do want to restrict registration, then I would suggest we have some kind of lightweight application process.  Presumably this wouldn’t be much of a strain on the staff because most people could be approved without much thought.  This way we could include all “borderline” people—why filter out people that could possibly contribute and really want to be there—and maybe some experts that aren’t necessarily core contributors but want to be or who can help us out.  For instance, if some of the zcash cryptographers wanted to show up to help us work on zero knowledge stuff, we would definitely want them there, even if they aren’t core contributors.

 

On the boot camps:  my big question about this is how can we incentivize enough of the core people to attend these to make it worth the time of new people.  Tacking these on to otherwise big events (i.e. the global forum and the member summit) seems like a good thing to do, but probably we need more.  Chris brought up the example of the Beijing hackfest as an example of where we didn’t get enough experts, and I agreed with his point.  Quite frankly I’m a bit worried about the attendance for the Hong Kong event.  I was planning on coming since I have to make a trip in March to Japan anyway, but how many “hackfest regular experts” are?  We need to make sure we have enough “experts” that it is easy for new people to approach them.  Can we twist some arms to get people to show?

 

If you’ve made it this far, thanks for reading.  Hopefully this makes some minimal amount of sense.

 

Thanks,

Hart

 

 

 

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Thursday, January 17, 2019 9:59 AM
To: tsc@...
Subject: Re: [Hyperledger TSC] Hyperledger BootCamp in Hong Kong Mar 7,9 2019

 

To clarify a bit...

 

The HK BootCamp would still welcome any maintainer or other core contributor who can make it and help us mentor new devs into becoming deeper users and contributors. Given what seemed like low numbers of such core contributors for the March event in HK, but still substantial dev interest locally, the choice really was to reframe the HK event as a Bootcamp, or cancel it.  We assumed that going forward as a BootCamp would be better than to cancel, but testing that assumption with the TSC for a few days by email might have been better.  At this point, can we go forward with the HK BootCamp?

 

The second part of this is really a discussion about the "Core Contributor summit" part.  Let me make Tracy's articulation of the rationale she had for making it "invite-only" a bit more explicit, and reframe it as a choice, so the TSC can discuss further and be the one to decide, and we can implement for whenever such a summit will be held (no planned time or location yet).

 

The choice is:

 

A) Core Contributor Summits are invite-only.  Invites are sent to Maintainers and to contributors as defined below.  Invites may be extended (by other Core Contributors, perhaps?) beyond the defined list for someone with clear commitment to contribute.  Invitees are strongly urged to attend so meaningful work can be accomplished, and cross-project conversations can happen.  On the upside, this might allow participants to feel safer in discussing sensitive topics.  On the downside, it may exclude people who would otherwise want to come but don't know others well enough to be on anyone's list.

 

B) Core Contributor Summits are not limited by invite.  Maintainers and other core contributors are strongly urged to attend, so each project has a critical mass of those maintainers and meaningful work can be accomplished, and cross-project conversations can happen. But anyone is allowed to register and attend, and is expected not to slow down discussions if they aren't up to speed on the issues.

 

In either case, Chatham House rules would apply, which means that you can share outside the meeting what was said in the meeting, but not who said it, unless they give permission.  Notes will still be published as an official record, but will record the overall discussion and decisions.

 

Of these two, which do people on the TSC prefer?  Open to a third way if one occurs to someone.

 

A little while ago I suggested Tracy take a look at how Linux Kernel Summits are run.  To my surprise, those are invite-only.  Invite-only discussions are not my style, and I feel like we do fight against riannatural tendencies to have dev discussions on private forums rather than where they should be (Jira, email, rocketchat, etc).  But, IMHO this is something the TSC should discuss and decide, not HL staff.

 

Brian

 

 

On 1/17/19 9:19 AM, Tracy Kuhrt wrote:

Hi, Shawn.

 

The name of the summit may be a bad one. The current proposal has the following regarding the participants:

A short list of contributors will be created that includes:

·  TSC members

·  Working group chairs and vice chairs

·  Active Core Contributors - defined as contributors who have contributed 80% of the code and have made a contribution in the last 6 months (as of January 15th, using the project reports tool, this list included 54 people)   

In addition to the above, anyone that suggests a topic is added to the short list of names. 

 

The program committee will use this list to determine who should receive an invite.

 

The proposal was intended to keep these summits (call them Core Contributor Summits if you will) limited to a small set of people to ensure that progress can be made on advancing Hyperledger's technical community and source bases. The goal of these summits are:

to encourage cross collaboration amongst the different projects that are part of Hyperledger. This cross collaboration can come in the form of education about each of the projects, specific work surrounding an architectural component of the frameworks (e.g., common consensus mechanisms), contribution or review of cross-project whitepapers developed by the different working groups, or other items that the maintainers feel is important to ensuring that we are one community.

 

with the topics including:

·  items that enhance cross collaboration amongst projects

·  items that are easier to resolve in person than over email

·  "information sharing" topics if they are clearly of interest to the wider development community (i.e., advanced training in topics that would be useful to all projects)

 

From your email, I hope I have addressed the maintainer vs. contributor question with the above. The question that may still be open is whether these summits should be open to any contributor or limited (as is currently proposed). I chose "invite only" because I stole a lot of what you see in the document from the Linux Kernel Maintainers Summit, and I thought it made sense to have a small set of people who would be able to more easily sit down and make decisions and hack out solutions focused on the goals. Another consideration is whether an open meeting would allow people to feel safe expressing their point of view under a set of Chatham House rules.

 

I am completely open to feedback though, and I would appreciate any feedback that you can provide either on the mailing list or by providing comments directly on the wiki page. In no way should you consider my attempt at documenting the Maintainers Summits as anything other than a straw man for people to rip apart and put back together again.

 

Thanks for the initial thoughts, and I look forward to hearing more from you and others. 

 

----
Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...

Hyperledger Chat: @tkuhrt

 

 

On Thu, Jan 17, 2019 at 9:32 AM Shawn Amundson <amundson@...> wrote:

The 'Maintainers Summit' idea probably deserves more community discussion. The current proposal would exclude most of the community, with most of the community hearing later "we decided this a the thing you were excluded from". Changing it to a 'Contributors Summit', where it is open to anyone who has materially been involved in HL projects would be healthier from a community perspective.

 

-Shawn

 

On Wed, Jan 16, 2019 at 10:20 PM Silona Bonewald <sbonewald@...> wrote:

Howdy,

 

I wanted to explain in more depth about why Hackfests are being cancelled.  Instead they are being replaced by different events with different audiences.

 

We are doing a Bootcamp in HK for the time we reserved for the HK HackFest.  There was considerable feedback about how the Hackfests were being run.  We noticed two major trends.

 

One that we needed a space to onboard new community members and contributors.  Many projects needed to learn how to onboard and create friendlier environments for the volunteers. In China, we have many members but not as much participation across the projects,  We wanted to directly address that need.  The event also gives maintainers a chance to recruit and increase diversity.  

 

The second trend is that we needed to have some deep discussions on Hyperledger as a whole for the maintainers.  We needed to document and make decisions as a group.  There is some overlap in that some maintainers still need to attend bootcamps.

 

The first event is going to be a BootCamp.  https://wiki2.hyperledger.org/display/events/Bootcamps

The Bootcamp's purpose is first to help newcomers more easily engage in the community.  The second purpose is to also help the Maintainers receive valuable feedback on how better to engage the community.  There will also we some "intermediate" level breakouts taking place at the bootcamp as well it is a very fluid format.  For example, the Ursa team will be working with interested Chinese companies about not just working on but leading the Chinese Crypto libraries.  

 

We are working to standardized the bootcamps so that other organizations can also lead their own.  We are creating an approval and coaching process.  Currently, we are talking to the BC govt about a smaller Indy, Ursa bootcamp, a DefCon village about an Ursa one, and the Denver startup community on one for Indy.   The are purposely have breakout sessions with varied levels of experience needed.

Basic requirements are they must complete are

1) The basic logistical checklist so we know things are well run

2) Transparently plan the breakout groups so that the CA team knows that the projects, workgroups and labs will be well represented

3) I'm sure as we iterate we'll create more ;-)

 

The second type of event is the Maintainers Summit.  These summits will have different themes but are much higher level in focus.  They will only available to maintainers and not the general public unlike the bootcamps. They will be held Chatham house rules so that companies can more easily collaborate and negotiate.  The first summit will be focused on the overall architecture of Hyperledger especially interoperability.  We, the CA team, are going to be doing individual "Deep Dives" with certain identified Projects beforehand to get a feel for the structure.  Tracy has been hard at work on this section in the wiki https://wiki2.hyperledger.org/display/events/Maintainers+Summits

 

I hope this clarifies things.  Please feel free to ask us questions and/or add them to the wiki sections that are live and in progress.

 

Thank you!

Silona


--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf



--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org


Re: [Hyperledger Identity WG] Identity Working Group update for Q1-2019

Vipin Bharathan
 

Hello Mark,

The papers are meant to complement each other. Since the Arch WG paper is meant to deal with System Identities which are the identities that control the nodes and our paper with Identities in general.and transactor/user/IoT Identities in particular. Also the Identity WG paper is much larger in scope.

We already had a discussion about this and decided that the papers should stay as they are for now. When the ID WG paper comes out we might present a combined paper later.

Best,
Vipin  

On Mon, Jan 21, 2019 at 3:43 PM Mark Wagner <mwagner@...> wrote:

Vipin

Thanks for the writeup. It was on time and on target for me.

I like the idea of having someone who greets and assimilates the new folks. I am curious to see how that works and if it can be a blueprint for other efforts within the broader community.

A few questions on the papers:
How similar are the papers, do they "compete/conflict" or "compliment" each other ?

do you feel that the TSC should have a discussion on the two different WGs producing Identity papers ?

thanks

-mark

On Sun, Jan 20, 2019 at 11:43 AM Vipin Bharathan <vipinsun@...> wrote:
Hi TSC members & HL Community,

Please review and let me know if you have questions or comments before the next TSC meeting of 01/25/2019. I have already sent this out to the IDWG list seeking comments and additions.

Advance engagement will help us to get the maximum out of the next TSC meeting where several items are up for discussion. I will also try to port this to new confluence website before our meeting.

Thanks,
Vipin 



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


Re: [Hyperledger Identity WG] Identity Working Group update for Q1-2019

mark wagner <mwagner@...>
 


Vipin

Thanks for the writeup. It was on time and on target for me.

I like the idea of having someone who greets and assimilates the new folks. I am curious to see how that works and if it can be a blueprint for other efforts within the broader community.

A few questions on the papers:
How similar are the papers, do they "compete/conflict" or "compliment" each other ?

do you feel that the TSC should have a discussion on the two different WGs producing Identity papers ?

thanks

-mark

On Sun, Jan 20, 2019 at 11:43 AM Vipin Bharathan <vipinsun@...> wrote:
Hi TSC members & HL Community,

Please review and let me know if you have questions or comments before the next TSC meeting of 01/25/2019. I have already sent this out to the IDWG list seeking comments and additions.

Advance engagement will help us to get the maximum out of the next TSC meeting where several items are up for discussion. I will also try to port this to new confluence website before our meeting.

Thanks,
Vipin 



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


Identity Working Group update for Q1-2019

Vipin Bharathan
 

Hi TSC members & HL Community,

Please review and let me know if you have questions or comments before the next TSC meeting of 01/25/2019. I have already sent this out to the IDWG list seeking comments and additions.

Advance engagement will help us to get the maximum out of the next TSC meeting where several items are up for discussion. I will also try to port this to new confluence website before our meeting.

Thanks,
Vipin 


Re: Guidelines for considering a new framework proposal

Nikolay Yushkevich <nikolai@...>
 

Hi Vipin, Tracy, others,

How about using Confluence commenting feature — we can try discussing the set of guidelines there.

Nikolai

On 10 Jan 2019, at 22:37, Vipin Bharathan <vipinsun@...> wrote:

Hello Tracy,
Thanks for this note.
In my opinion, the project proposal document is the right pace to add this. It already has some.guidelines (very slender) in Motivation and Context.
 Best,
Vipin

On Thu, Jan 10, 2019 at 11:50 AM Tracy Kuhrt <tkuhrt@...> wrote:
Hello, TSC members.

I am writing because Hyperledger staff members are often approached regarding proposals for a new framework as a top-level project to Hyperledger. Our response is usually to ask "what are the differentiating features for the framework", "have you considered adding those features to an existing framework", and "would you consider adding support to the different tools for the given framework". Instead of these questions, it would be ideal if we could draft a set of guidelines for people looking to propose a new framework for acceptance as a top-level project.

Please provide your thoughts in response to this email so that we can gather a set of guidelines for a new framework that the TSC would consider bringing to Hyperledger. Once we have a good set of guidelines, I will draft a wiki page for review.

----
Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...
Hyperledger Chat: @tkuhrt




Re: Hyperledger BootCamp in Hong Kong Mar 7,9 2019

Silona Bonewald <sbonewald@...>
 


This is a Mea Culpa email.   Ignorance isn't an excuse but I did want to explain the thinking behind what happened.  It's my mistake and I'm sorry for the confusion I caused by not keeping everyone informed.  Going forward, I'm gonna be sending a lot more little emails to this group.

I viewed the new Maintainers/Contributors Summit as the actual HackFest replacement TSC attendance wise.  A Summit is more of an "All Hands on Deck" type of an event.  I felt like I was postponing the "HackFest" pending reworking into a summit/think tank style structure.  I asked Tracy to very quickly post a proposal to the wiki so that we could start discussing it as a community and we could discuss it at the TSC meeting.

I did not view the bootcamp as a replacement other than - we still needed to take advantage of the timing and free space Julian obtained for us.  My decision was primarily driven by the fact we didn't feel like we could organize a complete and effective HackFest in time.  We did not have a date or location until a week ago.  The location opened up and we had to jump on it FAST!  So I compromised.  This did cause some confusion hence Ry saying "HackFest is cancelled" even though we closed the contract with the venue at the same time for a bootcamp.   The real answer is a good deal more complex than that...

I received primarily negative feedback about the current state of the HackFests during HGF.  My team and Julian had a deep conversation about what we thought the APAC market would need in an event.  We discussed the chicken and egg problem of how hard it is for most maintainers to travel to APAC but not really having enough local maintainers to really make a HackFest work on a short notice.  Julian said one of his main issues was getting people from the over 50 APAC member companies on-boarded and participating in the community.  I suggested taking advantage of the free space he had just found with doing a bootcamp instead of a HackFest.  It would be our first bootcamp.  It might be a little rough but better than not having an event.

This would give us time to work on reframing the HackFest into an event that has a few clearly defined deliverables like a Summit/Think Tank. 

We were already designing a generalized bootcamp formula.  My CA team realized we needed a recruiting/onboarding style event to be done regularly and distributed for our contributors and potential contributors.  We wanted more on-boarding style events to take place this year.  But we wanted a safer structure than the hackathons.  We started planning on-boarding events in India, S America and maybe Singapore for this year. 

The Indy and Ursa projects liked the idea of training bootcamps so much they asked if they could do a "one off" version.  Since my team was already talking about how to standardize it.  I decided to work with them on theirs.  We are discussing what the future approval process will be.  I felt safe working with these two teams because both projects did similar 4hr formats at the HGF.  We wanted to iterate on it and make it stronger!  So I viewed bootcamps as something new.  I did not see them as a HackFest replacement attendance wise.  I saw the bootcamps as a way for getting measurable participation and overcoming that scary "First edit" or "first Commit" and the thrill of the first acceptance.  I also saw it as a way for our maintainers to see first hand the affects they have on the newbies. Those people will go on to participate more and the maintainers can take a clearer mentorship role.

A bootcamp doesn't require the complete coverage of all HL's maintainers.  There could be many bootcamps.  Bootcamps have an inclusive model so people can self organize based on the resources available.  I view them as merger of a codeathon/unconference/training session.  The key takeaway from a codeathon is the wiki pre-planning. So for the bootcamps we will pre-planning the breakout sessions. Like an unconference, the attendees decide what those breakout sessions will be.  And we will as a team, target people ready and willing to onboard new people.   There is much flexibility built in regards to the scheduling on the breakouts.  So as Brian says, if a bunch arrives and decides to do a hard core session, they can.  The sign up spreadsheet for the Breakouts will indicate things like Level, Language, prereq, software needed, etc.

For this bootcamp in HK,  I am talking with Indy, Ursa, Cello, Caliper, the China Tech WG, and others about possible sessions.  They will each get planning pages on the wiki as we move forward.  We will be figuring out things like, size, timing, and placement of those sessions.  Dorothy and I have been talking with Marketing to see all the general materials cranked out by Tuesday.   She and I are also working with Events to nail down logistics and get registration ready by Tuesday. 

It is a BIG lift for the LF team to make this deadline.  Maybe I should have said "No" and decided to wait until April/May for a different event in APAC and possibly it could have been a summit.  But I wanted to do something in March even if it is a smaller event.  I really wanted to start iterating on it and taking advantage of the location and timing.  I may be over confident but I have run similar but much larger events in the past, so I think we can do it.

We have an EXTREMELY short window to get marketing and registration done before Feb 4th (which is really Jan 28th.)  Registration and marketing starts on the 22nd.  But after that, we focus on mentoring people on creating the breakout sessions.  These sessions are where my team will need the most help from the TSC in regards to recruiting. 

Having run several hardware startups, I am properly terrified of Chinese New Year.  It's hard to explain how thoroughly things shut down... even a couple of weeks advance becomes CRUNCH time.  Getting the possible attendee's attention in the next week and half is going to be a very heavy lift for Julian and his team.  I was distracted by all the logistics I had to get in focus quickly. So I did not inform the TSC.  I was also a bit to focused on getting very basic documentation up on the wiki before sending an email explaining the situation. But it is up and we are live editing it!  I hope it will be more polished by Tuesday!  https://wiki2.hyperledger.org/display/events/Hyperledger+BootCamp+-+Hong+Kong

As to Vipin's checklist,  these are all things we have been discussing organizationally for the bootcamps!   I will ask that for those discussions on the bootcamps that we have them publicly on the wiki.  You can do inline comments!  Right now I have the other members outside of HL staff that will be running bootcamps asking similar questions.  I don't want to lose these ideas esp the possible sessions. I would like them to be findable by the participant and organizers.  We might not be able to implement all of the ideas at each Bootcamp.   But they are inspiring to the person wanting to do a breakout session at the NEXT one!  I for one am very interested in posting re-usable training materials.  I believe Indy is already on it and will be sharing theirs so we can post links to them once created.

Also Hart - you are 100% right about tying the bootcamps to other events to help with maintainers' budget.  There is a big blockchain event in HK at the same time as this bootcamp on Mar 7th, 8th.  Julian is hoping to use it to his advantage :-)  If you are attending this conference in HK - we will ask you about leading a session!  The one-off bootcamps are also tied to events such as a BC govt event, Denver startup event w 18K people, and DefCon.  I used to do all my similar style events at SXSW and I always had a very full house :-)

I hope the site will be live on Tuesday and when it is - I will post it here to the list so we can all help promote it.

As for the postponed HackFest/Summit,  I'm glad to see the discussion here on the mailing list. 

Thank you for understanding,
Silona



On Fri, Jan 18, 2019 at 12:26 PM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

Agree with Hart.
Considering that the year of the pig is fast upon us (Feb 5) we have to get organized on this very fast. Let us get a vote going on the tsc by email, including a debate if anyone has objections, but get back right away, instead of waiting for TSC meeting to engage.
1. The idea of a contributors summit is great. Where meaty topics can be discussed without much of a preamble. I assume that this will not be taking place in HK in March. Please clarify. There are always going to be issues of inclusion, make the gating factor a willingness to suggest/lead a discussion and rough topics for this-maybe
2.For a bootcamp, as Hart said, we need experts to show up to make this a success- this might be the most fundamental problem.
- Loosely define what a Hyperledger bootcamp expectations are:
  • we understand that the bootcamp's overall aim is to increase community engagement; but what is in it for the attendees? especially the newbies or someone who has never heard of this before? Should there be not some "meat" instead of being a general marketing and documentation session to attract people?
  • I would suggest hitting the core concepts in Blockchain and then relating that to our work in Hyperledger  as the "meat". 
  • level of suggested general expertise (who is expected to attend)
  • level of general blockchain expertise needed. Developers? Business peole? both?
  • Teaser on what the breakout sections are are
  •  What if any level of hands-on engagement there will be (no point in having endless downloading of multiple components; spending the majority of time on sysadmin type activities)-  
  • Who are the experts who will lead the breakout sessions.
  • Language barrier (translators, slides in chinese alongside english?)
  • The great firewall- what can get through there if there are web based content.
  • Suggest that there should be some boilerplate slides on Blockchain/Hyperledger/WG or project specif stuff to be optionally repeated per session.
I know that there are commitments from several groups for breakout sessions. Chiefly Ursa, Indy, Cello, Caliper etc.
I had proposed a list of breakouts, maybe some that I can lead, but as a tentative list for all, during each of these generic ones we can talk about what work is going on in each framework around that, also challenge people to propose topics.
  1. A session on IDWG 
  2. One on Arch WG.  (Explain the consensus and smart contract white paper)
  3. Privacy & confidentiality 
  4. Interoperability - a survey- Fabric network interoperability, others if any
  5. Regulations and the blockchain - business
  6. Digital Tokens in Blockchain and in Hyperledger - business and technical 
  7. A survey of cryptographic techniques (primitives, data structures, protocols, development challenges) in Hyperledger and Blockchain - relate to Ursa
  8. Smart contract generation and transformation 
  9. Iroha session
  10. Iroha use cases in Cambodia
  11. Other use cases (Monatago)- Find Chinese/other Asian use cases
  12. Fabric
  13. Sawtooth
Some of these may seem advanced; but you can dial it down to the concepts and relate to general blockchain and show how people can get involved in each .

Exposing people to the depth of the ecosystem and they will respond in a positive way. Why should they devote time to Hyperledger instead of Ethereum or public Corda or anything like that.
If you have read until here you are brave.

Consistent with the year of the pig; wish you all prosperity and wealth!
Best,
Vipin

On Thu, Jan 17, 2019 at 9:23 PM hmontgomery@... <hmontgomery@...> wrote:

Adding my 2c on some of this:

 

On splitting the onboarding from the maintainer meetings:  this is a great idea and I’m glad we’re doing it.  I think this is pretty noncontroversial, though.

 

On invite-only stuff:   +1 to Brian and Shawn.  I really dislike the idea of invite-only summits.  At minimum, if we invite N people, the (N + 1)th person is always going to be upset and feel a little undervalued, particularly if the criteria for invitation aren’t completely transparent and clear (what is a “valued contributor” anyway?  Why 22 lines of code?).  If we announce that “maintainer summits” are for experienced/expert people only, I doubt we’ll get a lot of extraneous people, particularly if we don’t market them.  Requiring advance registration and not doing any marketing would seem like it would be sufficient at this point to deter people from showing up.  Maybe the Linux kernel and the devs behind it are famous enough that people would crash the maintainer summit, but I highly doubt that we are.

 

If we really do want to restrict registration, then I would suggest we have some kind of lightweight application process.  Presumably this wouldn’t be much of a strain on the staff because most people could be approved without much thought.  This way we could include all “borderline” people—why filter out people that could possibly contribute and really want to be there—and maybe some experts that aren’t necessarily core contributors but want to be or who can help us out.  For instance, if some of the zcash cryptographers wanted to show up to help us work on zero knowledge stuff, we would definitely want them there, even if they aren’t core contributors.

 

On the boot camps:  my big question about this is how can we incentivize enough of the core people to attend these to make it worth the time of new people.  Tacking these on to otherwise big events (i.e. the global forum and the member summit) seems like a good thing to do, but probably we need more.  Chris brought up the example of the Beijing hackfest as an example of where we didn’t get enough experts, and I agreed with his point.  Quite frankly I’m a bit worried about the attendance for the Hong Kong event.  I was planning on coming since I have to make a trip in March to Japan anyway, but how many “hackfest regular experts” are?  We need to make sure we have enough “experts” that it is easy for new people to approach them.  Can we twist some arms to get people to show?

 

If you’ve made it this far, thanks for reading.  Hopefully this makes some minimal amount of sense.

 

Thanks,

Hart

 

 

 

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Thursday, January 17, 2019 9:59 AM
To: tsc@...
Subject: Re: [Hyperledger TSC] Hyperledger BootCamp in Hong Kong Mar 7,9 2019

 

To clarify a bit...

 

The HK BootCamp would still welcome any maintainer or other core contributor who can make it and help us mentor new devs into becoming deeper users and contributors. Given what seemed like low numbers of such core contributors for the March event in HK, but still substantial dev interest locally, the choice really was to reframe the HK event as a Bootcamp, or cancel it.  We assumed that going forward as a BootCamp would be better than to cancel, but testing that assumption with the TSC for a few days by email might have been better.  At this point, can we go forward with the HK BootCamp?

 

The second part of this is really a discussion about the "Core Contributor summit" part.  Let me make Tracy's articulation of the rationale she had for making it "invite-only" a bit more explicit, and reframe it as a choice, so the TSC can discuss further and be the one to decide, and we can implement for whenever such a summit will be held (no planned time or location yet).

 

The choice is:

 

A) Core Contributor Summits are invite-only.  Invites are sent to Maintainers and to contributors as defined below.  Invites may be extended (by other Core Contributors, perhaps?) beyond the defined list for someone with clear commitment to contribute.  Invitees are strongly urged to attend so meaningful work can be accomplished, and cross-project conversations can happen.  On the upside, this might allow participants to feel safer in discussing sensitive topics.  On the downside, it may exclude people who would otherwise want to come but don't know others well enough to be on anyone's list.

 

B) Core Contributor Summits are not limited by invite.  Maintainers and other core contributors are strongly urged to attend, so each project has a critical mass of those maintainers and meaningful work can be accomplished, and cross-project conversations can happen. But anyone is allowed to register and attend, and is expected not to slow down discussions if they aren't up to speed on the issues.

 

In either case, Chatham House rules would apply, which means that you can share outside the meeting what was said in the meeting, but not who said it, unless they give permission.  Notes will still be published as an official record, but will record the overall discussion and decisions.

 

Of these two, which do people on the TSC prefer?  Open to a third way if one occurs to someone.

 

A little while ago I suggested Tracy take a look at how Linux Kernel Summits are run.  To my surprise, those are invite-only.  Invite-only discussions are not my style, and I feel like we do fight against riannatural tendencies to have dev discussions on private forums rather than where they should be (Jira, email, rocketchat, etc).  But, IMHO this is something the TSC should discuss and decide, not HL staff.

 

Brian

 

 

On 1/17/19 9:19 AM, Tracy Kuhrt wrote:

Hi, Shawn.

 

The name of the summit may be a bad one. The current proposal has the following regarding the participants:

A short list of contributors will be created that includes:

·  TSC members

·  Working group chairs and vice chairs

·  Active Core Contributors - defined as contributors who have contributed 80% of the code and have made a contribution in the last 6 months (as of January 15th, using the project reports tool, this list included 54 people)   

In addition to the above, anyone that suggests a topic is added to the short list of names. 

 

The program committee will use this list to determine who should receive an invite.

 

The proposal was intended to keep these summits (call them Core Contributor Summits if you will) limited to a small set of people to ensure that progress can be made on advancing Hyperledger's technical community and source bases. The goal of these summits are:

to encourage cross collaboration amongst the different projects that are part of Hyperledger. This cross collaboration can come in the form of education about each of the projects, specific work surrounding an architectural component of the frameworks (e.g., common consensus mechanisms), contribution or review of cross-project whitepapers developed by the different working groups, or other items that the maintainers feel is important to ensuring that we are one community.

 

with the topics including:

·  items that enhance cross collaboration amongst projects

·  items that are easier to resolve in person than over email

·  "information sharing" topics if they are clearly of interest to the wider development community (i.e., advanced training in topics that would be useful to all projects)

 

From your email, I hope I have addressed the maintainer vs. contributor question with the above. The question that may still be open is whether these summits should be open to any contributor or limited (as is currently proposed). I chose "invite only" because I stole a lot of what you see in the document from the Linux Kernel Maintainers Summit, and I thought it made sense to have a small set of people who would be able to more easily sit down and make decisions and hack out solutions focused on the goals. Another consideration is whether an open meeting would allow people to feel safe expressing their point of view under a set of Chatham House rules.

 

I am completely open to feedback though, and I would appreciate any feedback that you can provide either on the mailing list or by providing comments directly on the wiki page. In no way should you consider my attempt at documenting the Maintainers Summits as anything other than a straw man for people to rip apart and put back together again.

 

Thanks for the initial thoughts, and I look forward to hearing more from you and others. 

 

----
Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...

Hyperledger Chat: @tkuhrt

 

 

On Thu, Jan 17, 2019 at 9:32 AM Shawn Amundson <amundson@...> wrote:

The 'Maintainers Summit' idea probably deserves more community discussion. The current proposal would exclude most of the community, with most of the community hearing later "we decided this a the thing you were excluded from". Changing it to a 'Contributors Summit', where it is open to anyone who has materially been involved in HL projects would be healthier from a community perspective.

 

-Shawn

 

On Wed, Jan 16, 2019 at 10:20 PM Silona Bonewald <sbonewald@...> wrote:

Howdy,

 

I wanted to explain in more depth about why Hackfests are being cancelled.  Instead they are being replaced by different events with different audiences.

 

We are doing a Bootcamp in HK for the time we reserved for the HK HackFest.  There was considerable feedback about how the Hackfests were being run.  We noticed two major trends.

 

One that we needed a space to onboard new community members and contributors.  Many projects needed to learn how to onboard and create friendlier environments for the volunteers. In China, we have many members but not as much participation across the projects,  We wanted to directly address that need.  The event also gives maintainers a chance to recruit and increase diversity.  

 

The second trend is that we needed to have some deep discussions on Hyperledger as a whole for the maintainers.  We needed to document and make decisions as a group.  There is some overlap in that some maintainers still need to attend bootcamps.

 

The first event is going to be a BootCamp.  https://wiki2.hyperledger.org/display/events/Bootcamps

The Bootcamp's purpose is first to help newcomers more easily engage in the community.  The second purpose is to also help the Maintainers receive valuable feedback on how better to engage the community.  There will also we some "intermediate" level breakouts taking place at the bootcamp as well it is a very fluid format.  For example, the Ursa team will be working with interested Chinese companies about not just working on but leading the Chinese Crypto libraries.  

 

We are working to standardized the bootcamps so that other organizations can also lead their own.  We are creating an approval and coaching process.  Currently, we are talking to the BC govt about a smaller Indy, Ursa bootcamp, a DefCon village about an Ursa one, and the Denver startup community on one for Indy.   The are purposely have breakout sessions with varied levels of experience needed.

Basic requirements are they must complete are

1) The basic logistical checklist so we know things are well run

2) Transparently plan the breakout groups so that the CA team knows that the projects, workgroups and labs will be well represented

3) I'm sure as we iterate we'll create more ;-)

 

The second type of event is the Maintainers Summit.  These summits will have different themes but are much higher level in focus.  They will only available to maintainers and not the general public unlike the bootcamps. They will be held Chatham house rules so that companies can more easily collaborate and negotiate.  The first summit will be focused on the overall architecture of Hyperledger especially interoperability.  We, the CA team, are going to be doing individual "Deep Dives" with certain identified Projects beforehand to get a feel for the structure.  Tracy has been hard at work on this section in the wiki https://wiki2.hyperledger.org/display/events/Maintainers+Summits

 

I hope this clarifies things.  Please feel free to ask us questions and/or add them to the wiki sections that are live and in progress.

 

Thank you!

Silona


--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf



--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org

1921 - 1940 of 3892