Project Foundation Stages

The development of Wikijump should follow the deployment plan, or the ill-defined lack of a final state will result in endless development without a serious feeling of progress towards migration or effective prioritization.

This plan devises “stages”, which are groupings of releases which are targeted towards bringing the platform to a particular state. When a set of requirements are met, a stage can begin, and a set of changes in access patterns and platform migration can take place.

There are a number of features which are already full or partially implemented in the project, but are not currently expressed in the UI or usable. The goal of this setup is to organize remaining necessary work in such a way that higher priority items are focused on, and that there is centralized tracking for filling in missing holes throughout the project.

Note about Jira organization

There are extant labels with letters, such as stage-b. For now, these labels will be left as-is, and have no bearing on the plan below. The epic associated with each stage will be linked in its name.

Since epics cannot have other epics assigned to them, if there is a sub-epic which needs to be completed in its entirety for a stage, then it should be linked to the release stage epic using the “Requires” issue type.

Each stage’s “requirements” section lists the code changes that need to occur in order for that stage to be completed, and the “platform” sections lists all non-code changes, such as policy that needs to be written.

Please note that later stages are more likely to be incomplete as planning the exact scope of what makes sense to achieve there cannot be properly known until the project itself is closer to that point in time.

Stage 0 (Trial)

This is the first project stage. It is primarily a label rather than a deployment target, but will be notable for having an associated announcement. The announcement post will explain this plan and how we intended to roll out each stage and the associated deployment steps.

At the time of creation for this document, almost all the requirements here were already met. So, this stage is primarily about organizing, cleaning things up, and finishing up ongoing work into a release-ready state.

Requirements

Usable local deployment
Usable dev deployment
Support for users as a concept
Support for sites, categories, and pages as concepts
UI to view and edit user profile data
UI to view and edit pages (e.g. adding revisions)

Stage 1 (Foundations)

This project stage is marked by having a more complete set of actions available on users and pages, but which is overall still very non-comprehensive. This will also be the start of basic settings panels, which are expected to be in flux until designs and requirements stabilize. And, the foundations of solid internationalization support should be ensured.

Like with the Pre-Alpha stage (and every stage after), there will be an associated announcement.

Requirements

All UI available so far is properly localized (i.e. no UNTRANSLATED)
Create basic wjfiles server infrastructure
All infrastructure is available through IPv6
Page parent / child UI
Displays page breadcrumbs
Able to see page’s children
Page theme exposure
Support for page locks
UI for creating or removing page locks
UI for displaying current and historical locks
User sessions
Users are able to log in and log out
Session information is passed and processed in Framerail and DEEPWELL
Site actions require session data and perform authentication
User creation UI
Temporary support for passcode to limit user creation
Basic platform settings UI
Able to set free creation or requiring a passcode
Basic site settings UI
Able to set a site’s slug, name, and header information
Able to set a site’s default home page slug
Basic user settings UI
Able to set a user’s preferred language(s)
Able to modify a user’s email and password

Platform

Only developers may create users on the dev deploy

Stage 2 (Early)

This project stage is marked by having a more complete basic feature set. Most core operations on Wikidot are supported, and the project has a sufficient base to enable future changes to be made. This will be a longer stage than Stage 1, and marks the transition to larger stages with periodic intermediate releases.

Requirements

The page editor has basic functionality
The assumption is that this editor will be Sheaf or a modification of it, but ultimately what is called for is a usable editor which is more than just a basic HTML textarea.
Support for file operations (uploads, edits, deletes, all with corresponding file revisions)
Support for [[html]] blocks being exposed via URL
Support for [[code]] blocks being exposed via URL
CSS support in rendered pages
Support for attribution metadata
Stabilize/persist dev deployment
New database schema changes will require new migrations rather than migration amendments

Platform

Recruitment drive for active developers and contributors

Stage 3 (Access Alpha)

This project stage will be the first large stage, and is marked by implementing most of Wikidot’s primary feature set.

Requirements

Early platform database backup and recovery system. Basic infrastructure should be in place to export and import platform data.
Usable prod deployment
ftml should be capable of processing most Wikidot wikitext
Particularly, previously-filed issues regarding production inadequacies must be addressed during this stage.
Plan for modules and extended syntax begun
Code blocks have syntax highlighting
Tested procedure for importing/migrating sites from backup data
Page editor is usable and stable
Users should be able to activate imported Wikidot accounts
ListPages support
Sufficient moderation tooling in place
Platform should support creating, modifying, and automated enforcement of filters

Platform

Begin drafting proposals for social questions surrounding Wikijump as a platform. How it is governed, buy-in and ideas from various stakeholders, and beginning to compose a final list of site participants.
Formal terms of service (TOS) are drafted and ratified
Formal legal structure of the platform is determined and implemented
Platform is checked for GDPR compliance
Platform staff is organized and able to handle basic activity

Stage 4 (Access Beta)

This will also be a large stage, and is primarily marked by interactions and dialogue with users to understand needs and prioritize and fix platform shortcomings. There will not be a stable “production” during this time, instead it will be used to ensure that users are able to perform the work they are accustomed to.

Requirements:

Complete platform database backup and recovery system. It should be thoroughly tested, and a schedule for regular backup checks and recovery dry runs (on dev) should be set up.
Determine if any extra Wikidot information needs capturing (e.g. admin settings)
ftml should be capable of processing all Wikidot wikitext

Platform

Enable the general userbase to create new accounts and link their Wikidot accounts
A site migration order should be agreed on for the Gamma stages
Platform staff is organized and able to handle day-to-day activity

Stage 5 (Migration Alpha)

At this point, the platform should be stable and able to host general functions. So starting here, the effort will be on beginning the migration period for the new platform. That is, when Wikidot sites start moving over for real to use Wikijump as their new permanent home. It is expected that this will come with a number of operational and logistical difficulties, so it will start with smaller sites and those with fewer requirements. The stage will be marked with dialogue and work with these early platforms to ensure their workflows and needs are accounted for.

Requirements

Assess all open issues to determine prioritization
Discuss extension projects like Cogwork

Platform

Stage 6 (Migration Beta)

After all the early issues have been worked out, this release stage will be the bulk of the migration effort. Most of the large and heavily used sites will be migrated during this stage, and there will be a significant but gradual period as the bulk of Wikidot site activity begins moving over.

Requirements

Platform

Stage 7 (Migration Done)

This stage consists of the remaining sites being migrated, after most of the issues have been resolved and continued movements are incremental. Focus will be on cleanup, preparing for the Delta period, and ensuring that all of the site participants are safely off of Wikidot without any remaining data.

Requirements

Platform

All sites are migrated to Wikijump

Stage 8 (Stability)

Here, we work to pay down collected bug and operational issues, and determine priority for new feature work. Following this point, a new release system should be decided on to track continued development and migration work. For instance, a month-duration sprint system could be put in place in Jira to group each set of changes.

Platform

Monitor sites and platform administration for issues
Develop and ratify new release / stage cycle for continual maintenance and development