Documenting the Hypha customisation options

đź“ť Documentation
1

Primarily for @emlini @maxpearl:

This morning on a meeting with @frjo and @dluong discussion came up about documenting different Hypha customisation options.

For example:

Being able to configure Hypha’s behaviour when sufficient application reviews have been made. Right now, the application will not auto-advance to the next stage, even though it is technically possible for that to happen.

[Autoadvancing would save fund managers time to manually advance these submissions]

@frjo mentioned there are a lot of configurations are present in base.py, dev.py, and production.py files.

A few thoughts:

  • who are these configurations relevant to?
  • where in the documentation should each of these pieces of documentation exist?
  • what to do about configurations currently not customisable?

The applications process relevant configurations should be findable by fund organisation staff who are involved in choosing which workflow to implement as these configurations will be most useful to them, less so to the technical implementers.

I’ve opened an epic to track the different customisations people may want to request.

@allan @kfogel I think it would be useful if you could add any customisations you do for adopters? Alternatively make PRs to cover them? Just a thought.

I’ve added this on the next week’s maintainers call and next months adopters call agenda.

2

First off, I do think that documenting base.py, dev.py and production.py is a great idea! dev.py and production.py are primarily for developers and deployers, so I’m happy to work on documenting those.

base.py is mostly deployers, but there is some organizational stuff that deployers will probably need input from organizational stakeholders. I’m happy to start documenting it, with help from others - there’s a lot here I don’t know. And I can include info on which are tweakable, which are dangerous to change, and which should not be changed at all.

I added a new issue here in Github.

Thoughts?

3

I agree that this is something to be added to User docs as well. Might be in a “Workflows” page or “Setting up/Customizing Hypha” - introducing non-deployer staff members to the idea that they can do this, and introducing the customizable features (again, with links to the Dev page(s)).

I’m adding this to the Google Sheet I’m starting (right this minute!) on documentation content, organization, and suggestions and priorities for future content.

4

@zubakskees Would looking at the diff between main and our “changes for ARDC” branch at GitHub - OpenTechStrategies/hypha at ardc-branding be a good place to start, for figuring out what customizations/configurations would be good to document?

Flagging @emlini on this too, on the advice of @eriol (during the Adopters’ Meeting right now :slight_smile: ).

5

@bernard @frjo Are these issues related to this? just checking as I’m still getting used to the different language used across hypha functionality etc. Automate applications status transition based on review outcomes · Issue #2535 · HyphaApp/hypha · GitHub
Automatically add Wagtail system required field when creating new application forms · Issue #2275 · HyphaApp/hypha · GitHub

6

These two issues are new enhancements that we plan to add sometime in the future.

1 Like
7

Yes they’re exactly examples of what I meant.

1 Like