Project Plan Stages

The scope of work to be done as part of this project is rather extensive. While the needed work has been tracked in Jira, for instance using epics for groups of related changes that are part of an overall feature, previous attempts at an overarching prioritization have been difficult to effectively execute on. This has caused disparities within the project, where some areas are very thoroughly-developed, and others have little to nothing added.

The mere existence of such disparities is expected, for instance, in the presence of advanced features, but because some of these gaps extend to some basic areas (particularly in the frontend), the project overall has a feeling of being unfinished and undeveloped, since some areas being improved are not just invisible, but have no reasonable way of becoming so.

So, I have created a new plan for incrementally delivering the project through milestones which signify increasingly-expanding scope as the core parts of the project mature. For instance, a stage will be defined by whether it is open to new users, and the migration status of existing Wikidot sites.

You can read through the plan document here: https://scuttle.atlassian.net/wiki/spaces/WD/pages/1711079430/Project+Foundation+Stages

Originally, in the plan each stage was named using Greek letters. However I have changed them to be strictly numbered instead, with an attached brief description to denote the purpose of that stage. This is because use of terms like “alpha” and “beta” have prior associations regarding what they mean in terms of software development, which can distort project expectations, and also do not account for the time required to do the migration, which is a sizeable effort in and of itself. Fitting all of the development into two stages to fit the “alpha” and “beta” understanding (or a similarly small set of stages) would not be sufficient or useful as a project plan. This is similar to a planning issue the project had previously, where the 1.0 release was seen as having to contain everything, with only a limited number of intermediate stages prior. This caused the requirement list to rapidly expand, essentially degrading any project planning to “all of this has to be done now”, which made effective prioritization very difficult.

Instead, we are focusing on progress and laying foundations rather than getting things perfect from the start. For one, this means that the project will not be particularly aesthetic, with the goal being the existence and basic function of, say, a web component rather than it looking amazing. We can polish things in later stages, it’s more important that we continually carry development momentum.

As described in the document, each “stage” will contain a set of over-arching goals to achieve, rather than a specific list of changes. Particularly, each stage is defined in terms of where it puts the platform in terms of stability and migration status. A summary of each of the stages follows:

  • Stage 0 (Trial) — This is a small stage, largely composed of items already implemented in the project. This is our trial run of the new plan, where we make sure that the most basic fundamentals are in order.
  • Stage 1 (Foundations) — This stage addresses base groupings of features that will be later built on, and begins the work of removing some of the early “to-do”-type stubs present in the project. Basic features should be implemented or have groundwork laid for them.
  • Stage 2 (Early) — This stage focuses on core Wikidot operations. The goal is for there to be enough of a project and developmental base to be able to easily recruit new developers, designers, translators, and other contributors to the project.
  • Stage 3 (Access Alpha) — At this point, we will set up a basic production environment and begin inviting select users to use it and offer feedback. Support for existing Wikidot data and workflows will be stabilized, and work will begin on proper long-term infrastructure, both technical (e.g. backups) and social (e.g. means of governance).
  • Stage 4 (Access Beta) — Once we have a production environment and the ability to maintain and moderate it, we will slowly begin opening it up to regular users for testing and review. This stage will be marked by the effort to ensure that everything we do on Wikidot is either supported on the new platform or has an acceptable replacement.
  • Stage 5 (Migration Alpha) — This refers to the start of the overall migration effort itself, as sites begin officially moving from Wikidot to the new platform. In the early stages, we will be selective in the sites moved over to most effectively test the migration process and the platform’s capabilities.
  • Stage 6 (Migration Beta) — Once the migration process is deemed to be reasonably solid, the main migration effort will begin, with most sites being moved over in this period. Development efforts will focus on issues affecting the migration process.
  • Stage 7 (Migration Done) — At this point, the focus will be on verification that all relevant data lives in Wikijump and there isn’t any needed information hosted only on Wikidot. The remaining sites intended for platform inclusion will be moved at this time.
  • Stage 8 (Stability) — This stage will be the final within this migration plan, and marks the beginning of stability. Work will focus on fixing bugs and determining prioritization for new features. At this point, the Wikijump hosted platform will have a usable system for deciding and implementing policy, ratifying development plans, and further efforts.

By laying out the intended series of steps, this should hopefully improve understanding of what the effort involves and the kinds of project work that will be prioritized at each stage.

Of course, like all plans, the details are subject to change depending on how real-world conditions evolve. Some bullets on the list may move earlier or later, and part of that is under your control! For instance, there is no reason that discussions surrounding platform governance and policy must begin in the Closed Beta stage if people are interested in working on that sooner.

Author: aismallard

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.