Read-only documents

We are working on history and starting permissions re-work next week. It’s hard to provide ETA, but I do hope it will be from 2 to 4 months (not a promise).


Another approach, especially for a knowledge base or handbook is to let everyone contribute by “proposing changes” that are reviewed and accepted/rejected by the maintainer of the page.
Gitlab Handbook (Handbook | GitLab) does that. It is really good to have a culture of participation, decentralizing documentation, but still, keep it under control. At GitLab it is implemented using git and merge requests (similar to GitHub pull requests), so a bit technical for non-tech people.

Fibery could have a similar feature, with an editing workflow extension, reusing the assignee field:

  • edits are pending, not visible to others, or could be via Comments maybe?
  • assignees receive a notification
  • they have a button to accept/reject the edits
    The input of changes could be done with the inline comment feature, adding another action than “resolve” for the editor assignee, but not sure it is the best idea to mix the features.
    Another interesting property of using git for the Gitlab handbook is that someone can create a bigger change that affects multiple pages, that will be reviewed and accepted/change as atomic. When you start to have a big knowledge base, some “doc refactoring” will happen (reorganizing the pages, table of content, renaming, etc.)
    Also, Rich Edit field changes are not tracked, so the “modified date” field is not right, nor the activity stream, so not possible to see what has changed. This should be fixed for the feature to be usable.

@mdubakov I’m the only one who needed an editing workflow (a simple static one with one level of approbation is good enough)?


@JMaynier I guess permission feature for the read-only is in development.

Seems like approval process you suggested should be created as a separate one.

1 Like

Indeed. If I were on Fibery team I’d fork the above post to a new feature request topic…