Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit our Code of Conduct: Hyperledger Code of Conduct
Announcements
- The Hyperledger /dev/weekly developer newsletter goes out each Friday to hundreds of Hyperledger developers. It is a collaborative effort. If you have a project release, pull request, community event, and/or relevant article you would like highlighted next week, please leave a comment for consideration on the upcoming newsletter wiki page.
Quarterly reports
- 2022 Q2 Hyperledger Firefly (due )
...
Discussion
- Hyperledger TSC Transition Discussion
- 6/16 TSC Transition Discussion Notes:
- Arun
- New additional comments
- Current TSC accepts projects that are not solutions oriented, statement in deck "new mission will accept solutions as well into HL umbrella"
- solutions solving tech problems or end user?
- Tracy:
- current mission in charter, update 3-6 months ago
- originally - single source, now multiple things
- This org defines/decides if it makes sense for a project to come into HL, not changing things with this slide but to reflect how mission has changed from 2017-today
- Arun
- question - really like suggestion about end user, like CNCF, delegate some recommendations that end user tech could come into tsc
- Tracy -
- no prob, taking look at other projects and way they are forming their technical committee, oversight and advisory, is important, as mentioned the end user tech advisory board at CNCF is something we don't have today, does it make sense for HL to create in the future
- Other comments in slide deck since we last reviewed
- Arun's comment June 12 3:31am - suggestion around how we choose the different groups to be elected and represented
- Arun
- can talk thru it
- saw was a proposed selection process, likes some elements, collecting thoughts, def of TSC/TAC left blank
- saw some comments about group of project vs single project forming own TSC
- if we are leaving this to individual projects where they can form own committee, can at least get groups of projects together as part of TAC
- governance structure around it, group of proiects bringing something together and roadmap, would benefit multiple projects, help projects like Aries (island project), help Sawtooth, transact, etc: related. Fabric, large community spanning multiple layers
- Suggestion: how do we form the TAC
- instead of having representation from ind projects, each grad projects selects one rep
- could become more crowded as more graduate
- these TSC groups we create, formed under gov struct, get to rep 1 person at TAC
- rep group and rep overall HL charter
- for smaller projects or incubating, would be nice if we have rep as well
- could follow election process
- und current election process, multiple challenges, easiest for smaller projects only consider maintainers for those projects for consideration
- TAC/TSC someone involved on regular basis
- could still be part of TSC for that project group
- non-code contributors - critical community group - where proposal like end user tech in the picture
- what is their objective, what responsibility, how they bring value to larger community - still needs to be thought through
- Tracy - still changes to how this (TSC ) is made up in the future
- Angelo -
- way TSC committee selected, needs upper bound on the size of the TAC
- mission - message - trivial but blockchain and distributed ledger - shall we drop one of the two terms? why both?
- Tracy -
- leave mission question out of this for now, external to this discussion, BUT does have ? about upper-bound
- do you have an idea of what you think correct Upper Bound is for TAC?
- Angelo
- Each project elects a member doesn't work
- maybe each project nominates and then election amongst them
- we can say size isn't a problem
- but if each active project, maybe other bodies, among these people an election, community will vote, and then decide whats the subset of the TAC
- Tracy - no specific #?
- Angelo - 9!
- Danno
- last week, proposal detailed on wiki, addresses problems
- /wiki/spaces/~shemnon/pages/22577226
- writing too much into the charter
- let each group set their own rules
- proposed: 11 members
- ACTIVE project maintainers select 5 members (most active in codebase and projects)
- gov board select 4 more members (9 members)
- 9 TAC members selects last 2 members (11 total TAC members)
- brings it closer to how it works
- reserved seat? sure. Secret open ballot?
- Gov Board selects 4 - reps paying members of HL
- based on those 4, they select 4 more
- balances
- decide how these 4 get selected
- Voting, replacement, vacancies
- getting to much into writing too many details in the charter
- let TAC make decisions
- otherwise amending the charter every year (Not great)
- Tracy
- observer status missing?
- Danno -
- didn't write obs status, just selection process of TAC
- Troy
- hearing proposals, thought:
- complexity
- current process other than issues about selecting who is contributing code has benefit of simplicity
- choose upper bound of candidate, conributor select them, simple process
- hope for, if we make it more complicated, link it to goals and impacts and if we cant link it we keep it simple and not change the process
- Tracy
- in slide deck last week, did have certain reasons for evolving TSC
- reasons - mission and charter has changed
- the TSC then-now, based on single or/codebase we are all supporting which is not the case w/ 14 projects we have
- we don't steer, we provide guidance and provide oversight
- ensuring diversity of voice for diff projects
- goals
- agree if we don't have a reason to change, lets not
- initial goals set out
- Jim
- like proposal Danno shared
- fundamentals - 2 fold, TSC member value is having a forward look to und when a new project proposal comes on, having tech background and knowing industry reqs to make a proper judgement to accept or not
- first responsibility of new TAC
- second, day to day, und needs of current projects and provide better services and change policies (new task forces, etc.)(
- to serve these roles the best, the members should come from contributors community (key)
- feels 11 is prob right number
- agrees with Troy - not sure the thinking of the 2 additional members added by existing 9 members
- felt like let community elect? 7 identified and GB ultimately decide whats missing and PLACE remaining 4
- proposing to merge the last 2 into the contributor group so it is 7+4
- Nathan
- +1 for Jim
- diversity can't become more imp than sustainability
- is one of these structures better for funding and getting people to join
- make a real diff to sustainability
- still little nervous about what this does to how org evolves over time
- idea that a project becomes more pop and gains influence or less pop and loses influence
- worried we have a tech oversight committee with more groupthink, and hurts projects with more diverse thinking
- some of the projects we have now would have come to HL with one of these structures as more homogenous and less accepting (umbrella strategy)
- really important active commiters make up oversight committee passing policy
- easy to make decisions if we aren't impacted by them
- needs to be people who are in the code
- not sure how to answer the question what can help membership base grow
- getting questions answered little by little
- Tracy - followup ?
- mentioned IF this was the struct when HL was formed, we would end up with sit where some of the projects we have now wouldn't be here, what do you think going forward to would look like with that lens? do you think we would have same difficulty moving forward, projects diverse in nature and not one single aspect of codebase
- Nathan
- past, TSC elected body, lot of shear on what mission was, easy to propose and fickle to approve
- meant things could get thru is you went and did the footwork of getting votes, easy to get thru gauntlet with work
- oversight committee of membership - shifts
- rev stream depends on it more-so than tech reqs
- even if not that committee approve, has perception
- when a new project comes, I want to host here vs going on my own, HL right place for me to be, fears about what happens, how governance evolves, amplified by paid membership
- customers and companies haven't joined yet, don't know value in the future, are these people going to crush me, changes power dynamic, should I fork or join
- Hart
- one of the reasons we do want to switch, inspired by getting more project to join
- lot of people told us, HL has TSC, tells projects what to do, make the decision
- had to explain, TSC doesn't micromange projects, doesn't tell them what to do w/ high level of detail
- to address Nathan's point, one of the reasons pushing for this change, assuage fears of people or projects who want to come onboard
- not sure,
- point 2 - not sure having gov board appointing people to TAC would change things, would nominate people known to the community
- issue of unpredictability of tsc, if they had breakfast or not, TSC members perceived as not willing to go against company's interest, thats not true but perception
- tied to GB might not hurt us in perception
- Danno proposed CNCF structure - maintainers, then GB then TAC adds
- structured to allow group to fill gaps
- goal - tac would address any blind spots with those final selection
- Tracy -
- other piece to clarify, members in Danno's proposal are from pool of people who submitted nominations
- not adding someone not nominated
- "here's the pool, Project maintainers select 5, gb selects from remaining pool, TAC selects from remaining pool" - only selecting from that pool
- Troy
- current proposal if you make it simpler, is a simple change over current process
- 11 members chosen by active project maintainers
- concern - some projects have too many members, simplest change to put cap on per-project or per-company membership
- start simple and und if meeting goals rather than going more complicated and working backwards
- Dave
- agree with what troy was saying, hybrid continuity - keep community vote, let GB fill a few positions based on diversity/sustainability, keep it simple and towards core objectives
- Hart
- with respect to simplicity and process, we are having discussion that CNCF had several years ago, shortcut/copy their work, follow their results
- similar scenario, this is what they came up with
- why we haven't just thought about only the simplest things
- Ry
- current election process is not sustainable, don't want to do it again
- tried/failed last year
- don't want to use the current voter process, maintainers is smaller and easier to find population
- Dave -
- fine with that
- talked about community voting - happy w/ maintainers (to troy's points)
- Tracy -
- go back, review notes, updates and changes to Danno's proposals, hopefully be able to have something to write down and provide input
- closing meeting.
- Arun
Project Proposals (from hyperledger/hyperledger-hips)
...