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]
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.
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 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)).
).