Monthly Ideation meeting: 2022 April 26th

🧑🏿‍🤝‍🧑🏻 Meetings Ideation
1

Logistics

2022-04-26T13:00:00Z→2022-04-26T13:50:00Z

:tv: Google meet room: https://meet.google.com/nuq-pztb-asu

If you’d like access to the google meet room, send a message to the @maintainers group. If you’d like to be added to the calendar invite please DM @eriol .

:writing_hand: Who will take notes? :raised_hands:
To take notes, all’s you got to do is make a riseup note pad here: https://pad.riseup.net/

Today’s Riseup pad: Riseup Pad

Monthly Ideation meeting: 2022 April 26th

Topic: Hypha Governance: Reading, discussion, commenting

Github issue/META/EPIC link: N/A

Relevant we.hypha posts links: Maintainer’s Call 19th April 2022

Relevant document: Hypha Governance_Public - Google Docs

Previous notes on the topic

Clarifying the topic

  • Understand better from OTF as the next steps from here? Version state of this document

  • What is still in discussion and what might not be?

  • Go through the comments or comments there are questions for and get context so edits are reflective of the goals/views

  • Making changes that match the aims and contexts that we have here

  • Discussion to learn more, make final changes and share a finalised document

  • Finalised document will be the last chance (as of now) to make change requests

Questions for discussion

  • N/A

Notes

  • Running through comments as per comment

  • AP: Adding line numbers into these notes will happen post meeting < Probably not needed now

  • Notes are also being taken inside the google document

  • Adding test.apply hypha website + Zulip into line X

  • Focuses on hypha core OSS and not independant instances

  • Expectations of forking or not and clarity of language on independant and language confusion throughout the document.

  • A glossary or unifying the language could help

  • Cross project (feature effort) & Adopters instances & Independant instances

  • It’s about what people can do with the code under the BSD license → Anyone can do whatever they like from a legal perspective re. license ‘This is release under a BSD’ license so means x. vs the social governance + code of conduct.

  • Will point to the licnese

  • Tried to use some terms that folks are using within hypha

  • Adopters are implementers? Or are Implementers mutually exclusive

  • Term success was dicussed and might be contextualised within the mission statement

  • Owner is the entity that owns IP related to Hypha which as of now is OTF

  • Does the owner have veto change power over others → How can someone be an owner of an open source project? why is there an owner?

  • What is the owner role as it interacts with other adopters, implementers, maintainers etc.

  • Legally, OTF is responsible for the IP related to Hypha.

  • Protecting orgs around that role is important + the governance allows for the involvement and collaboration of other folks involved in hypha

  • Investing and maintaining hypha means it won’t disappear if others are using it plus it’ll be security audited.

  • Our goal is that the maintainers (+ Adopters) play the role in making decisions about Hypha. If in the case these entities cannot make a decision then OTF would step in to decide and take direction and a decision has to be made.

  • ^ More specificity would be useful on the above, if someone coming into the project.

  • SOP’s have clarified that.

  • In practice in OSS the one who does stuff you own it, if you don’t do stuff you don’t own it but also legally from a liability perspective (origin creator or creator org).

  • Perhaps defining OTF as an entity would help under the owner heading so that it’s clearly legal

  • Issue is a general term used in the doc

  • Reasonable time frame was left open ended for maintainers to define and not impose an arbituary time frame. Thinking about saying if OTF step in tcould send a notification of that lack of decision and then owner comes in tomake final decision.

  • Create a system going forward that makes the maintainers the main decision making body and representative of the ‘people/orgs that use hypha’

  • Maintainers elected by the adopter community on annual basis.

  • Question: So each Adopter organization selects one maintainer to represent their interests?

  • Annual vote for the future. Adopter could vote a maintainer.

  • Voting for maintainer collectively rather than selecting individuals and then putting them forward

  • If indivuals are making decisions as maintainers, they should not be profiting from their work on hypha.

  • e.g. Avoids a maintainer voting on work that they then implement by being paid to work on

  • What happens if someone decides they need to leave? if that’s what they’ve been funded from? Sustainability issue

  • Does a line of a maintainer that want to make a decision?

  • Ths document is thinking about the future

  • Maintainer role will be useful in the future

  • Moving on to implementer

  • progressive model to make clear how decisions are made

  • a multi-step process to identify or define who “implementers” are

  • Removing maintainers will be added and considered

  • SOP process will be where ‘What is the process for this?’ dev and design will be detailed and refined.

  • Design on hypha oss core vs. design on hypha instances that go to hypha core oss

  • Managing an invidual instance can be different and will be different for some.

  • Some discussion on contractual relationships and work on Hypha

  • Discussion about Apache governance + who is paid for what work on OSS

  • Conflict of interest discussion, acknowledging conflict of interest, remove voting, could be brought into the maintainer role section.

  • Was a motion to remove the Implementers section

  • Representing an organisation that is using hypha vs. an org that is being contracted or an individual