The present approach has been “Full Wikijump”, wherein a feature-complete and compatible version of Wikijump is the goal, where it can be a replacement platform with essential parity to move onto in one, relatively-quick move. With the current manpower and resources the project has, this will take too long, and given recent events, a more expeditious approach is needed.
This document seeks to analyze “Minimal Wikijump”. This is an alternate approach to the platform, wherein the priority is not completeness, but rather speed. An extremely minimal set of features to target will be developed below, with all others, including those which we will eventually implement for completeness, being shed in the interest of immediately developing a replacement platform which progressively expands its compatibility with development time. The set of tasks to be completed must be as minimal as possible. In this approach, platform transition will be an even longer process, where a parallel platform exists for some time as it slowly grows and pulls production data.
Feature List
This section lists potential features for Wikijump, and triages them based on strict priority. It then explains what resources will be required to implement them, and any notes about modifications to enhance overall productivity.
The project will also be initially separated into “stages”, each given a letter of the alphabet, given labels such as stage-a, stage-b, etc. While the priority assessments will initially line up with the priority assessments given below, after Stage A, this will begin to shift. Each stage will encapsulate a group of changes which are the triaged as important during that period. Especially as we get to Priority C and D items, they will be split into more refined levels as needed.
Each priority assessment gives a value to describe the triage ordering for project tasks:
A / Core feature – Required for even the most minimal workable implementation of Wikijump. Such items must be reduced to the greatest extent possible.
B / Main feature – Not strictly required, but an important feature to be implemented when feasible. This assessment includes items which are stubbed for core work and implemented later.
C / Delayed feature – Features which will are entirely delayed until the platform is more stable and complete.
D / Stretch feature – Features which are “nice to haves”, and may never be implemented if time pressures are not eventually relieved.
Each implementation difficulty describes the overall cost of implementing it to an acceptable bound:
4 / Intensive – The task is a sizeable project in its own right, and will need to be decomposed into smaller tasks. Unless it cannot be broken into separate requirements with differing priorities, it should be split so that its subtasks can be triaged more effectively.
3 / Significant – The task will require a significant amount of effort. Approximate time cost is on the scale of months.
2 / Standard – The task will require a typical amount of effort. Approximate time cost is on the scale of a week or two.
1 / Trivial – Work on this task is non-zero but not significant. It could be implemented in a day or less.
0 / No extra cost – Already implemented as part of other work.
Each status refers to the current condition of the task:
Proposed – The task is not queued for work.
Pending – The task will be completed as part of the current project plan, but has not yet been started.
Incomplete – The task has some progress towards it, but it is not complete.
Finished – The task is already complete, or is implemented to the extent that completion is trivial.
You can click each column on the table to sort by it.
Feature or project task | Wikijump implementation and comments | Priority Assessment | Implementation Difficulty | Status |
|---|---|---|---|---|
Pages | Pages and revisions along with basic methods of interaction. Includes consistency constraints such as per-site slug uniqueness. | A | N/A | Finished |
Sites | Sites which are namespaces for pages, have a separate membership, and configurable local settings. | A | 3 | Incomplete |
Users | Individual accounts on the platform, along with basic authentication and biographical information. A stubbed | B | 3 | Incomplete |
Localization | System for ensuring the platform can be natively available in non-English languages. | A | 3 | Finished |
Translations | Translations for all message strings and other localization items, to make the platform available in all languages needed. | A | 4 | Incomplete |
Frontend | A basic implementation of the web server and frontend system, enabling new views and components to be added as necessary. | A | 4 | In Progress |
Wikitext (page compilation) | Bringing ftml up to parity with Wikidot, save for parser items which have been split out (see below). WJ-819 - Getting issue details... STATUS | A | 3 | Incomplete |
ListPages module | Implement both the module parsing and backend logic to permit ListPages queries to be carried out. This includes its use in “offset pages”. | C | 4 | Pending |
Native multi-part pages | WJ-1034 - Getting issue details... STATUS | D | 4 | Proposed |
Other modules (wikitext) | Includes all other modules which can be utilized in Wikidot’s syntax system. This will require analysis to break into more specific tasks. | C | 4 | Pending |
Bibliographies (wikitext) | WJ-822 - Getting issue details... STATUS | C | 2 | Pending |
Page includes | Connecting the various include systems within ftml to the actual backend, enabling pages to be actually included in others. | B | 3 | Pending |
Native components (aka “Cogwork”) | WJ-181 - Getting issue details... STATUS | D | 4 | Proposed |
Page editing | A novel native editor based on CodeMirror, called Sheaf, has been developed. Further work is needed to complete it and integrate it into the overall system. | B | 3 | In Progress |
Themes | Implement a native means of allowing for user-generated page themes. Not to be confused with Wikidot’s native, admin-only themes feature. | C | 3 | Proposed |
Categories | The grouping of pages into categories, suffixed with | A | 2 | Incomplete |
Categories read/write restrictions | Methods of utilizing category permissions to restrict access to pages within them. Requires implementation of user groups. | C | 3 | Proposed |
Tags | Tags are isolated strings which can be attached to a page, and enabling the grouping of pages which contain a given tag. | B | N/A | Finished |
Tag search | A feature which enables advanced searches on tags. This includes searching by multiple tags, the absence of a tag, etc. See Crom Tag Search. | C | 3 | Proposed |
Tag enforcement | A system around tags to ensure that they exist, prescribing rules around their use and application, and other features to manage their use on large sites. | D | 4 | Proposed |
Page locks | Methods of disabling edits to pages based on the lock type and the user’s groups. | C | 3 | Proposed |
Automated anti-vandalism | Systems for automatically detecting and reporting or reverting vandalism. WJ-276 - Getting issue details... STATUS | D | 4 | Proposed |
Page rating | A method of casting votes on a page, which are essentially tuples of | A | 2 | In Progress |
Page scoring | A system which can produce scores for pages based on the votes that have been cast for them. This also includes a means of changing the vote kind (i.e. what values are permitted). | C | 3 | Proposed |
Files | A system for tracking and storing uploaded blobs as “files”, and exposing them for use. | B | 3 | In Progress |
File revisions | A method of ensuring all changes to files are versioned and can be reverted if needed. | C | 3 | In Progress |
Redirects | A mean for pages to simply redirect to another destination. The Wikidot redirect module is essentially syntax like any other, but this should also record it as metadata so that pages can later be identified as redirects in listings and other contexts. | B | 2 | Pending |
Redirect restrictions | A system which enables the use of redirects to be restricted. For instance, on-site redirects only, or no redirects, for users which do not have permissions enabling them to create or change redirects. | D | 3 | Proposed |
Site search | Feature to permit searching across a site for particular content. Should be able to search both pages and forums. | C | 3 | Proposed |
Forums (Wikidot parity) | The addition of a forum system which can represent existing Wikidot forum threads and allow for continued discussion in that pattern. | C | 4 | Pending |
Forums (Enhancements) | Improvements and new features in the forum system (such as being able to lock individual posts) beyond that which Wikidot provides. | D | 3 | Proposed |
User DMs | A means of permitting users to send messages to each other directly. Decisions must be made regarding use of end-to-end encryption and the process of procuring and executing warrants. | C | 4 | Proposed |
Multi-factor authentication (MFA) | An implementation of MFA to secure high-value user accounts. | C | 3 | In Progress |
Site membership | A distinction between users who are members of a site and users who are not (“guests”). | B | 3 | Pending |
Site applications | A method of permitting non-members to apply for site membership, configurable in a manner similar to Wikidot. | B | 3 | Pending |
Member groups | Distinct from site membership, users who are members can belong to several groups, which carry on permissions and other capabilities. | C | 4 | Proposed |
Site settings panel | A native system for adjusting the permissions and settings of a site. Some form of this is necessary for other configurable features of a site. | B | 3 | Pending |
Start page | A site should be able to configure an arbitrary page as its “start page”, that is the page that is displayed if no slug is explicitly set. | B | 3 | Pending |
General-purpose public API | An API available to the public which can perform all the actions that a user can perform on the site, but through a well-designed interface. This is distinct from an internal API or one designed for use by a browser client. | C | 4 | Proposed |
Native draft feature | The ability to have drafts as a first-class feature rather than as normal pages on a “sandbox” wiki, including features such as auto-import. | D | 4 | Proposed |
Content bridge | A system to permit ingesting content from some well-structured source (probably SCUTTLE) to store as Wikijump data. This is necessary for importing extant Wikidot data. | B | 3 | Proposed |
Deployment Process
This describes the modified deployment process for the Minimal Wikijump plan, which will have a much longer incubation and transition period than originally planned for. It will take place in several stages:
Ephemeral writes, developer only
Ephemeral writes, closed alpha
Limited writes, open beta (extant Wikidot users only)
Full mirroring, open beta (new user registrations allowed)
Source of truth, Wikidot is read-only.
Source of truth, beginning A/B redirecting guest users.
Final transition, Wikidot is redirect only.
This is the general plan and should be modified as each particular step approaches. Additionally, producing a strategic order of sites to onboard is of high importance. These stages do not have to occur in sequence for all sites, but should reflect real status.