Maintainer’s Call 8th February 2022

🧑🏿‍🤝‍🧑🏻 Meetings Maintainers
1

Logistics

:calendar: 2022-02-08T14:00:00Z→2022-02-08T14:50:00Z

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

  • If you’d like access, send a message to the @maintainers group.

Agenda

  • :speaking_head: Anyone needs any specific time to discuss ongoing work?

    • Eriol: Proposal - Do we feel like weekly maintainers is working for it’s intended purposes? they are good as weekly meetings when there’s lots of new releases with lots of new information but last week we slipped into ‘ideation mode’ with headless Hypha. Shall we move maintainers to every two weeks and add in Open Ideation meeting space - #3 by eriol into the alternating week?

  • :file_cabinet: Fredrik files (review of recent releases , active dev tasks/bugs)

    • Eriol - Question: are all the other adopters - ARDC, DFF, Reset, DDP on forks or clones of the Hypha OSS? → response is unsure @Eriol will ask each Adopter maintainer

  • :notebook: Documentation Corner

    • Add here

  • :couch_and_lamp: Adoptor Maintainer Corner *(if we have multiple adopters in the call please keep updates on adoptor specific features as brief as possible! :bowing_man: )

    • Di’s suggestion for FAQ &
    • Eriol: Any updates on OTF’s: ’ Looked at the wording of messages in moving status between stages - emails/comms .’ Did the conclusion to ‘does Bernard need to see these from an OSS pov’ get resolved?

  • :art: UX Design Corner

    • Add here

  • :triangular_ruler: PM Corner

  • :business_suit_levitating: Any Other Business or ‘Proposals ongoing’

:page_facing_up: Notes

  • Copy paste Rise Up Pad notes here once meeting is finished.

Attending: Di, Slammer, Bernard, Eriol, Emily, Blah,
Apologies:

Agenda

  • Does anyone needs any specific time to discuss ongoing work?

    • Eriol: Proposal - Do we feel like weekly maintainers is working for it’s intended purposes? they are good as weekly meetings when there’s lots of new releases with lots of new information but last week we slipped into ‘ideation mode’ with headless Hypha. Shall we move maintainers to every two weeks and add in Open Ideation meeting space - #3 by eriol into the alternating week?

  • Fredrik files (review of recent releases ( https://github.com/HyphaApp/hypha/releases ) active dev tasks/bugs)

    • Django updates & wagtail updates going well epic exists

    • Eriol - Question: are all the other adopters - ARDC, DFF, Reset, DDP on forks or clones of the Hypha OSS? → response is unsure @Eriol will ask each Adopter maintainer

  • Documentation Corner

    • Goal to do some Hypha work this week!

    • Eriol will pair with Emily on Friday 8am EST work on FAQ’s docs

  • Adoptor Maintainer Corner (if we have multiple adopters in the call please keep updates on adoptor specific features as brief as possible!)**

    • Di’s suggestion for FAQ &

    • See bottom of doc for some ideas of FAQ’s

    • Eriol: Any updates on OTF’s: ’ Looked at the wording of messages in moving status between stages - emails/comms .’ Did the conclusion to ‘does Emily/Bernard need to see these from an OSS pov’ get resolved?

    • Bernard: if they’re in OTF’s translation file, then Bernard didn’t need to review them with his “Hypha-Core hat” on, but if this is going to be pushed upstream into Hypha core, then yes.

    • Wording was very OTF specific

    • @Fredrik will make this call if the OTF wording needed to made into a translation string for OSS.

    • Maintainers need the translation strings non-adopter specific one to review the language @eriol to add an issue

    • @Di to share wording that OTF is using

    • here’s the existing strings for rewording: hypha/django.po at main · HyphaApp/hypha · GitHub @eriol make an issue in repo for work

  • UX Design Corner

    • @Eriol to put some finance updates from design on Adopters call agenda

  • PM Corner

    • Eriol: Proposal - Do we feel like weekly maintainers is working for it’s intended purposes? they are good as weekly meetings when there’s lots of new releases with lots of new information but last week we slipped into ‘ideation mode’ with headless Hypha. Shall we move maintainers to every two weeks and add in Open Ideation meeting space - #3 by eriol into the alternating week?

    • Emily: Good idea - dedicated bloack of time to do this ideation more regularly. Some trouble understanding what the SOW is for each meeting and understanding that. Do we need an ideation “tag” for meeting notes?

    • Bernard:What happens in each type of meeting? 1 month of maintainer call time. At least one thing on agenda and shared widely.

    • Eriol: big, new topics that take up maintainer’s call (e.g. Headless Hypha) can happen in the “ideation” meeting

    • Blah: Regular maintainer’s meetings are good for generating seeds of these ideas; suggests last maintainer’s call of each month is ideation-focused (discuss pro/cons for new ideas, feasibility, etc)

    • Once a month would be nice.

    • If we’re discussing a number of topics in depth, then maybe better to call it “Deep dive into [topic]”?

    • That meeting needs to have at least 1 topic on the agenda.

    • Timing of those meetings relative to monthly adopters call?

    • Understand the decision making process that happens on maintainers. process is being refinied both in governance & all folks have chane to respond.

    • Slammer: what are people getting out of weekly maintainers (vs bi-weekly maintainers) with knowledge output, questions, syncing, sprints + seasons etc. Ideation call once a month → what is decision making power and process. Only one topic focus. Ends early fine! Iterate on this and see what happens.

    • Di: zulip & we ideas are plentiful there from other adopters! More likely to join a meeting for that.

    • Reporting epic started: [META/EPIC] Reporting · Issue #2708 · HyphaApp/hypha · GitHub

    • Bernard: Proposal - Making Hypha-app GH issues great again! (Baasically…some issue pruning/making METAs/connecting to others) This would be helpful for the Design Team (and I guess others). absolutely on my radar! proposal for rebasing adaptation on third here: 3 proposals for adopter and maintainer input: Open Roadmap, voting / 'wish list' and Quarterly Milestone Rebase process

    • @Eriol set up the triage/grooming/rebasing meeting for end of March Q1

    • Dan, Di, Slammer ok with process → no delete issues, closing is fine.

  • Any Other Business or ‘Proposals ongoing’

    Is this below to add into docs?: is yes then @emily ping!

Frequently Asked Questions (FAQ)

  1. Is NEW adopter onboarding available?

    Yes, we will have a 1:1 meeting, new adopter onboarding documentation, online forum to access the Hypha community. During the 1:1 meeting we provide you with tips and guidance on how your funding mechanism could be steered through Hypha. The information on workflows, processes, documents you share with us is confidential and it is entirely up to your discretion.

    Please contact [ ] if you would like to have a meeting or join this online forum

2. How could I contribute to this open source project?

We are humbled and grateful for any code, design, documentation, bug reports, virtual hugs, and any other forms of contributions made to Hypha.

We aim to foster design and development improvements that would benefit the entire Hypha community. For major changes that would impact Hypha’s core infrastructure and cross-projects, we encourage a public discussion to help the community become aware of the need and the problems contributors are working to solve. This public discussion can often help contributors recruit others to help do the work, as well as gather feedback.

We are interested in learning more about any challenges and feedback on how to improve the platform. Please submit your bug reports to the main repo here: [insert GitHub repo]

Adopters could also provide input into new designs, user research, etc. There are several types of contributions you can make:

  • Adopter contributions/user agreements

  • UX contributions/user agreements

  • Design contributions/user agreements

3. Is there a governance structure for adopters deploying their own forks and instances?

Instances working on their own development fork can make their own technical decisions and manage their day-to-day activities, create new repositories in their orgs, etc., with independence and autonomy. Implementers determine their own decision making processes at the instance level, and evolve their own self-governance based on the skills assembled.

[di]:

1) Questions about the voting/wish list: [3 proposals for adopter and maintainer input: Open Roadmap, voting / 'wish list' and Quarterly Milestone Rebase process]

  • Could we have a documented process on the full workflow of the voting/wish list approach? ← Eriol: yes I can model this in a flow chart with timelines/scales

  • For example, the workflow could elaborate on what happens when an adopter is interested in developing a particular feature. Will they take ownership or lead the development of this feature?

  • Eriol:IMO Adopters always ‘lead’ feature development that are significant and specific. I see the wishlist process more as a way of understanding how intensely multiple adopters want ‘X’ feature/enhancement/non-critical dev/ui/ux bug fix done e.g. File Tab - All adopters will benefit from the files tab work,twon options of many to hvae files tab worked on is:

  • 1 - A single adopter decides it’s critical to their use of Hypha to complete and therefore they ‘adopt’ the epic/issue in Hypha OSS/core and then resource it in the way they see fit. That is done on their instance of Hypha and then pushed ‘upstream’ (or our approximation of ‘upstream’ into Hypha OSS/core). In a wish list process if other Adopters have ‘upvoted’ that feature as important to them, but not critical to there work and therefore not leading a resourced design/dev solution then it’s up to them how they want to involved the interested ‘upvote’ adopter in the build. Or/and it is the Hypha OSS Product Manager’s role to understand the ‘upvoter adopters needs’ and advocate for them with the lead Adopter.

  • 2 - No single Adopter deems a feature/enhancement/non-critical dev/ui/ux bug fix critical to their work but they want to ‘upvote’ it as a focus that after a wishlist vote round, if there are a majority vote on a feature/enhancement/non-critical dev/ui/ux bug fix (say 4/1 majority) that the OSS PM take the responsibility to lead how that build would look and the costs of the work hours might come out of the (not yet in existence) ‘OSS money pot’ or each adopter commits design/dev resources/time or $$ to that work. We could also look at this like ‘crowd funding’ a feature/enhancement/non-critical dev/ui/ux bug fix but only between current adopters at present.

  • How often will voting take place?

  • I would say it’s manage to look quarterly but ambitious with adopter lead features and our current work spread. bi-yearly might be more feasible.

  • Is there a voting structure, i.e., consensus?

  • When I participated in a similar process before it was that each instance (adopter) got [3] votes per [time period] to assign to a focus they want. This was great for understanding what adopters wanted to happen that would help them, but couldn’t yet fund. Happy to use this as a ‘spring board’ for finding the best way for us though!

  • Who or which entity gets to vote?

  • Good question! I imagine that adopters can nominate a single rep or they could have a wishlist vote meeting - that’s what happened in the previous place I was in that did this - One adopter had 6+ staff and OSS volunteers and they spent 1 hour per quarter deciding from the existing backlog of issues which got their 3 votes. They did keyword searches rather than knowing all the issue content though!

  • Could you please provide examples or scenarios of this approach being carried out?

  • Here’s where I learned about a voting proceedure: First dot-voting experiment on roadmap priorization - Process - Open Food Network Community

  • Here’s some context on how OFN used it for their ‘papercuts’(small bugs and improvement issues) and wishlist: Proposal for Software Improvement: Streamline Papercuts & Wishlist Process - Process - Open Food Network Community

  • And how the OFN dev team ‘estimated’ these kinds of work: How we estimate wishlist items and epics - #4 by Erioldoesdesign - Process - Open Food Network Community

  1. How does Open Roadmap, ZenHub, and features and enhancements requests work together? I’m a little unclear on this question but I’m gonna try to clarify below

  • Open Roadmap - triage of existing issues ← I see the open roadmap as needing two things 1. An indication of what ‘wrok’ is being done by adopters on their own instances that plans to come upstream during [time frame] and 2. wishlist work or multiple adopter work that has been agreed on in the open.

  • ZenHub - collect from each instance Zenhub (if permissions are enabled) can 'pull in multiple open (not closed or archived) repos so that in one place the OSS Hypha PM’s can see what work is being done on roadmap items and what state they are in (e.g. in progress, blocked, completed, upstream contribted etc.)

  • Features and enhancements requests - ongoing requests Features and enhancements are types of work that can be on adopters ‘wishlists’ and ‘upvoted on’ or 'taken to be ‘adopter lead’ as resourcing. I don’t see these dissapearing just understanding how important each one is for each adopter over time

  1. “Currently how issues get prioritised is based on the primary adopters that founded the OSS Hypha product. [How can] their needs are balanced with newer adopters that do not ‘invest’ in Hypha but are as equal stakeholders(?) in the adoption of the tool.”

Is a lack of “balance” in Hypha functionalities a challenge for adopters? Are there examples or could we discuss this further as a group at the summit or adopter’s meeting?

  • I’m unsure of what’s being asked here around ‘balance’ of functionalities? I think I’d like an example if you can? so e.g. finance has been built primarily with OTF’s needs in mind (because they funded it) but are you asking if a ‘balanced’ way is if other adopters are also involved in resourcing/helping move that along would make it more balanced?
  1. Is there a documented process for developing and implementing proposed procedural changes or proposals like ZenHub, Voting/Wish List, etc? What is the next step or follow-up after posting a proposal on We.Hypha.App?

Sociocracy proposal framework < this was the framework I proposed in Q3 last year in a maintainer call and then an adopter call. The only thing missing from this is time limits for agreeing that a proposal is ‘safe enough to try’ and clarified enough by the proposer. In sociocracy a proposal does not get implemented if something is not ‘safe enough to try’ and has ‘critical concerns’ if there are critical concerns about a proposal then it is adapted to address the critcial concern or safety issue.

I am familiar with the sociocracy framework you proposed back in Q3. Is a proposal “passed” via a lazy concensus? How long is a proposal on hold for feedback/input/vote before it’s implemented? deffo lazy consenses please offer feedback if you have changes

2

@Maintainers Any topics for discussion?

@Adopters Any updates/topics relevant for maintainers?

3

Link to new FAQ issue here

2 Likes