...
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.
...
- 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
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 international support should be ensured.
...
- Only developers may create users on the dev deploy
...
Stage 2
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 the Pre-Alpha, and marks the transition to larger stages with periodic intermediate releases.
...
- 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 3 ()
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.
...
- 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 4 (Migration Alpha)
Unlike “alpha” and “beta”, the word “gamma” is not often used in release terminology. Here it will refer to the migration period for the 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.
...
- Assess all open issues to determine prioritization
- Discuss extension projects like Cogwork
Platform
...
Stage 5 (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 6 (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.
...
- All sites are migrated to Wikijump
...
Stage 7 (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.
...