# Maintainer’s Call 8th February 2022
**URL:** https://we.hypha.app/t/maintainer-s-call-8th-february-2022/248
**Category:** Maintainers
**Created:** [February 5, 2022, 5:06pm UTC](https://we.hypha.app/t/maintainer-s-call-8th-february-2022/248 "2022-02-05T17:06:02Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@eriol](https://we.hypha.app/u/eriol)
#### Post date: [February 5, 2022, 5:06pm UTC](https://we.hypha.app/t/maintainer-s-call-8th-february-2022/248/1 "2022-02-05T17:06:02Z")
## Logistics
📅 2022-02-08T14:00:00Z→2022-02-08T14:50:00Z
📺 Google meet room: [https://meet.google.com/nuq-pztb-asu](https://meet.google.com/nuq-pztb-asu)
- If you’d like access, send a message to the [@maintainers](https://we.hypha.app/groups/maintainers) group.
## Agenda
- ✍ - Who will take notes? 🙌
To take notes, all’s you got to do is make a riseup note pad here: [https://pad.riseup.net/](https://pad.riseup.net/)
- Today’s Riseup pad:[Riseup Pad](https://pad.riseup.net/p/F4-omns3EXkOCyaIzAUp-keep)
- 🗣 Anyone needs any specific time to discuss ongoing work?
- 🗄 Fredrik files (review of [recent releases](https://github.com/HyphaApp/hypha/releases), active dev tasks/bugs)
- 📓 Documentation Corner
- 🛋 Adoptor Maintainer Corner \*(if we have multiple adopters in the call please keep updates on adoptor specific features as brief as possible! 🙇♂️ )
- 🎨 UX Design Corner
- 📐 PM Corner
- 🕴 Any Other Business or ‘Proposals ongoing’
## 📄 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?**
- **Fredrik files (review of recent releases (** [**https://github.com/HyphaApp/hypha/releases**](https://github.com/HyphaApp/hypha/releases) **) active dev tasks/bugs)**
- **Documentation Corner**
- **Adoptor Maintainer Corner** (if we have multiple adopters in the call please keep updates on adoptor specific features as brief as possible!)\*\*
- **UX Design Corner**
- **PM Corner**
- **Any Other Business or ‘Proposals ongoing’**
**Frequently Asked Questions (FAQ)**
1. **Is NEW adopter onboarding available?**
**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: [[https://we.hypha.app/t/3-proposals-for-adopter-and-maintainer-input-open-roadmap-voting-wish-list-and-quarterly-milestone-rebase-process/233](https://we.hypha.app/t/3-proposals-for-adopter-and-maintainer-input-open-roadmap-voting-wish-list-and-quarterly-milestone-rebase-process/233)]**
- 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](https://community.openfoodnetwork.org/t/first-dot-voting-experiment-on-roadmap-priorization/1260)
- 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](https://community.openfoodnetwork.org/t/proposal-for-software-improvement-streamline-papercuts-wishlist-process/2298)
- 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](https://community.openfoodnetwork.org/t/how-we-estimate-wishlist-items-and-epics/1556/4)
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?
[https://we.hypha.app/t/sociocracy-proposal-framework/171](https://we.hypha.app/t/sociocracy-proposal-framework/171) \< 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
---
### Author:  [@eriol](https://we.hypha.app/u/eriol)
#### Post date: [February 5, 2022, 5:06pm UTC](https://we.hypha.app/t/maintainer-s-call-8th-february-2022/248/2 "2022-02-05T17:06:29Z")
[@Maintainers](https://we.hypha.app/groups/maintainers) Any topics for discussion?
[@Adopters](https://we.hypha.app/groups/adopters) Any updates/topics relevant for maintainers?
---
### Author:  [@emlini](https://we.hypha.app/u/emlini)
#### Post date: [February 8, 2022, 5:58pm UTC](https://we.hypha.app/t/maintainer-s-call-8th-february-2022/248/3 "2022-02-08T17:58:58Z")
Link to new FAQ issue [here](https://github.com/HyphaApp/hypha-docs/issues/33#issue-1127585112)