Now that the documentation site is live at
https://elifepathways.github.io/kotahi-docs and deploys automatically from
main, we need a few decisions about who can change it and how incoming
reports are handled.
Raising this as an issue rather than quietly configuring it, because it affects
the whole team.
Context
- Pushing to
main publishes to the public site in about two minutes, with no
review step in between.
- The site currently carries a lot of content recovered from the retired
kotahi.community (archived 13 July 2026) that has not been verified
against a running Kotahi. Pages say so via a status banner.
- Some pages carry deliberately-worded caveats — withheld screenshots, unresolved
positioning, the service-models-vs-tiers conflict. Those wordings shouldn't be
changed casually.
Decisions needed
1. Who has write access?
Check Settings → Collaborators and teams. If the org grants members write access
by default, that's a wider group than we may have intended. Is that what we want?
2. Should main require a pull request and a review?
- Leave open: anyone with write access publishes directly. Fastest to fix
typos; no safety net.
- Add branch protection: changes go via PR with one approval. Slower, but
nothing reaches the public site unreviewed.
Recommendation: add protection before we point a custom domain at it, since that
is the point it starts looking official.
3. Who watches issues and pull requests?
The site's Contact page tells people to open an issue here for bugs, so this is
now a real support route. It needs at least one named person, and ideally the
issues should auto-add to the Kotahi project board so they surface in our normal
triage rather than only in someone's notifications.
4. Do we want external contributions at all?
Every page has an "Edit page" link. People without write access get a fork and a
pull request, so nothing changes without review. Worth confirming we're happy to
receive those, since it's a genuine benefit of being open source.
Not blocking
None of this stops the site being used. It's about deciding the rules while the
site is still new rather than after something goes wrong.
Now that the documentation site is live at
https://elifepathways.github.io/kotahi-docs and deploys automatically from
main, we need a few decisions about who can change it and how incomingreports are handled.
Raising this as an issue rather than quietly configuring it, because it affects
the whole team.
Context
mainpublishes to the public site in about two minutes, with noreview step in between.
kotahi.community(archived 13 July 2026) that has not been verifiedagainst a running Kotahi. Pages say so via a status banner.
positioning, the service-models-vs-tiers conflict. Those wordings shouldn't be
changed casually.
Decisions needed
1. Who has write access?
Check Settings → Collaborators and teams. If the org grants members write access
by default, that's a wider group than we may have intended. Is that what we want?
2. Should
mainrequire a pull request and a review?typos; no safety net.
nothing reaches the public site unreviewed.
Recommendation: add protection before we point a custom domain at it, since that
is the point it starts looking official.
3. Who watches issues and pull requests?
The site's Contact page tells people to open an issue here for bugs, so this is
now a real support route. It needs at least one named person, and ideally the
issues should auto-add to the Kotahi project board so they surface in our normal
triage rather than only in someone's notifications.
4. Do we want external contributions at all?
Every page has an "Edit page" link. People without write access get a fork and a
pull request, so nothing changes without review. Worth confirming we're happy to
receive those, since it's a genuine benefit of being open source.
Not blocking
None of this stops the site being used. It's about deciding the rules while the
site is still new rather than after something goes wrong.