Logistics
2022-02-22T14:00:00Z→2022-02-22T14:50:00Z
Google meet room: https://meet.google.com/nuq-pztb-asu
- If you’d like access, send a message to the @maintainers group.
Monthly Ideation meeting: 2022 February 22nd
Topic: Headless Hypha aka Hypha as an application management tool without the ‘Front End’ website.
Github issue/META/EPIC link: [META/EPIC] Discovery with Adopters re. expectations of Hypha.app / 'headless' Hypha · Issue #2707 · HyphaApp/hypha · GitHub
Relevant we.hypha posts links:
- Maintainers call 8th feb 2022: Maintainer’s Call 8th February 2022
- Maintainers call 1st of feb 2011: Maintainer’s Call 1st February 2022
Rise up pad: Riseup Pad
Previous notes on the topic
Discussion about a pieces of work re. 'Headless Hypha & Hypha.app’
-
Website tied to Wagtail website interface moving away from - decoupling website from application process.
-
Dan suggested we make more clear maybe on hypha.app the fact that we don’t recommend using Hypha for both application and front-end website; we are working toward making Hypha more “headless” and able to be integrated with multiple 3rd-party sites (e.g. Wordpress, Hugo, Ghost, etc. based websites), but it’s not quite there yet
-
A follow up question for Fredrik from a technical spike pov to ask what platforms he might have considered as workable - Hugo, Ghost, Wordpress etc.
-
Fredrik: Hypha API is the work. generic API’s to implement on anything - Hypha releases a 'apply only’function.
-
Do adopters want to ‘publish’ their API ‘hooks’ into whatever CMS/website they use.
-
json file that has API endpoint definitions (did I remember that right?) yup so people can make use of that with different plug-ins. API will be platform-agnostic.
-
Hypha.app is a ‘headless tool’ that powers the application. Discovery with Adopters re. expectations of Hypha.app
-
Skin templates for public website e.g. Wagtail front-facing website. Other Adopters don’t use this theme because it doesn’t match what they want from their website. Adopters want to use Hypha for both ‘apply backend’ only or ‘front website + apply backend’ how is this supported going forward?
-
Sounds like a design research piece with both current adopters + potential funders that could be adopters.
Clarifying the topic
What research needs doing before we can make a decision about what is supported in Hypha?
- List item
Who (organisation wise) needs to consent to documenting a website process
- List item
Meeting Notes:
Scope of the ideation meeting (for broader docs)
Current ways to suggest new features/ideas: we.hypha post, or issue (meta/epic) on github - both asynchronous, this meeting is intended to be a real-time:
-
a place for ideas to be discussed that are new features/exploration/big discussions/
-
the sort of things that are hard to put down on paper just yet and where the maintainers may have different levels of understanding
Clarifying the topic
What research needs doing before we can make a decision about what is supported in Hypha?
-
e.g application support vs. front-end support
-
common terms
-
Front-end: interfaces that actual people engage in (e.g. website or Hypha app interface)
-
Back-end: interfaces that components (e.g. only for people who have login access)
-
Front and back end interface via the API, sometimes directly connected
-
Fredrick has proposed an API for public part of Hypha that any other application (e.g. Wordpress) can interface with
-
Public - displaying certain content and private (log in area)
-
FE for private - define a request/application etc. Private FE space
-
FE public - expose the text of a request, the fields etc. any generic website to link to that (from public hypha) and that be pulled into that website to feed into that ‘any old website’
-
Don’t have to make the application public - link to a ‘stand alone page’ that embeds in a (e.g. Wordpress)
-
BE: apply.opentech.fund
-
FE: your application at opentech.fund
-
for OTF & Reset right now they manage both the public and private but soon only apply.hypha back end. The website is ‘seperated’ from that space.
-
Would a ‘fund’ not be needed anymore given that a website is not needed anymore
-
RAW data that describes how a fund work but can be styled by any websites system.
-
You can currently create a fund in hypha and if you know the URL you can submit to that fund.
Bernards 3 options:
-
Hypha has a management UI for managing fund stuff & Hypha has a application UI to display the fund stuff that looks the same as the funder website but is not the same
-
Hypha has a management UI to create funds & manage applications & organization uses ‘website UI’ (that can recieve an API endpoint from Hypha) to display the application part that applicants would actually access and fill out
-
Info requested from Hypha and displayed on organisations website. ‘See who we fund’ rendered in wordpress but info pulled from Hypha e.g. Project name, description, fund name, advisory council.
-
^^^^ All of the above could be done within an API via end points and ‘choosable’.
-
These are all potential use cases. What is the dev process and dev resources to make the mvp of this idea?
-
Bernard’s research: Most Adopters are using Wordpress CMS Hosted (apart from Reset & OTF)
Who (organisation wise) needs to consent to documenting a website process
-
If adopter is doing particular implementation of headless Hypha, how do we want what they are doing to be shared, what do we want them to support
-
Research into wordpress would need to be done (especially for the plugin part?)
-
Do we as Hypha OSS maintain a primary ‘plugin’
-
Do communities/adopters maintain a plugin that is specific to them and then encourage forks for new/existing adopters?
-
More removed from the database e.g. Hugo that queries the hypha api.
-
Support for a plugin is difficult and time consuming.
What is the dev process and dev resources to make the mvp of this idea?
-
Research into wordpress would need to be done e.g. plugin
-
Security related considerations for this?
-
Who is the best for that?
-
Foundations are already laid for API - which of the ‘3’ options do we want to focus on first?
-
Move the front end to API would be fairly straightforward for existing devs.
-
What other API’s/end points/plugins would interplay with this? e.g. CRM systems?
-
For option 1 reskinning the Wagtail to look like the existing website.
-
Spike on options
-
which is easier
-
which is more Sustainable
-
Notes for Eriol: Look at CiviCRM and OFN’s API.