RFC: Editoria Community Open Roadmap process
We are about to open up feature requests for a larger group of organisations. So, we need to come up with a transparent and fair way for organisations to request a feature that the Editoria Core team will develop.
Bugs are separate to this proposal and should be logged as per normal (ie. a normal issue logging process in this repo).
Orgs or individuals with dev resources that intend to build something themselves should ignore this process and instead should open a RFC if the code is intended to be included into Editoria core (documentation forthcoming).
Who can make a Feature Proposal?
Anyone. Individual or org. Commercial, non-commercial, closed content, open, libraries, publishers, publishing staff, authors, reviewers.... Anyone and everyone can make a proposal.
Scope of Proposals
There are no hard rules to this, beyond a best effort to make the proposal easy to understand. In general a proposal can be as large or small as you feel it needs to be. If there are numerous distinct features then these should all be separate proposals. If there is a larger development that requires lots of changes to realise its vision then it is preferred that this is a single Feature Proposal. For example, numerous small changes to the Book Builder should have one feature proposal per item. However, if the proposal was to create an entirely new Book Builder interface or a complex new feature with many facets to extend the Book export workflow (for example) then these larger developments should each be written up as a single Feature Proposal.
Features that effect any part of the Editoria workflow should be made here. For example, if a change to wax, paged.js, xsweet etc is to be made it should be made here and the Editoria core team will do the sorting/re-direction. We need to do this because the ecosystem of Editoria is complex and we should not expect end-users (which I hope will be where we receive the majority of our proposals) to understand this technical ecosystem.
- An issue in this repo must be created with the prefix Feature Proposal followed by a short title eg Feature Proposal: Add logout button to Book Builder
- The proposal must state the org (or individual if no org) making the proposal. This is to help us keep a fair distribution of attention to participating orgs from the Editoria Core team.
- The proposal should begin with a short Summary statement that indicates the end goal of the feature and the roles effected. These statements are to give us a sense of who the primary end user is for the feature and what they are trying to achieve.
- Following on from this initial statement the main body of the proposal must follow describing the feature. Preferably this is explained entirely from the point of view of the end-user. No technical details need be included unless it is a technical proposal (eg recommended standards for accessibility of EPUBS should contain the relevant technical detail). The aim of this section is to spell out the proposal as clearly as possible in a very readable format from an end-users perspective. Screenshots or quick sketches of what the feature user interfaces look like is very much advised if appropriate (in rough form - a photo of a hand drawn sketch is completely acceptable for example).
The community manager (alison) should be available to help community members write and submit proposals.
Discussion and Voting
We encourage the community to comment on proposals (in GitLab using the comment feature within each proposal) to help shape them and vote on them using the up/down votes in GitLab.
Every 3 months the Editoria Core team will:
- review the proposals
- ask for more details where necessary
- make an initial triage (Adam and Alison)
- make a final decision of what will be included in the next quarters roadmap (Adam and Alexis)
- create a table on the Editoria ReadMe documenting the roadmap
- announce the roadmap on the Editoria.pub site
- Feature Proposals that did not make the cut for that quarters roadmap will be closed but may be re-opened and re-submitted at a later date for the next/another quarter
How decisions will be made
The Editoria Core team will consider each proposal on its own merits. There will not be a formal metric system (highest GitLab votes does not automatically guarantee a Feature Proposal will be accepted although it will have a positive influence), rather the team will look at forming a coherent roadmap, choosing items in a consensus based discussion based on the following factors:
- proposals made by orgs or individuals using Editoria in production and active in the community will get the highest attention
- proposals made by two or more organisations/individuals collaborating on a feature will get more attention that those made by one org or individual
- proposals that get more community discussion and review (up votes included), and respond to community input will get more attention than those that do not.
- clear proposals will be preferred over less clear proposals
- the Editoria Core team will endeavor to choose proposals for the quarterly roadmap that represent a broad spectrum of the community
Who Makes the Decision?
The Editoria Core team will be facilitated by Adam Hyde and will include the Editoria Community Manager (Alison), and the Editoria lead dev (Alexis). At times the group will also include others as needed (eg Christos for decisions involving wax etc).