Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 45 Next »

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.

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

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

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 : (for example, system: or theme:) which

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 (user_id, vote_value), where the vote value is an integer constrained by the page’s voting settings. However for this task, no vote value constraints exist, but will be implemented below instead.

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

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:

  1. Read-only, developer only

  2. Ephemeral writes, developer only

  3. Ephemeral writes, closed alpha

  4. Limited writes, open beta

  5. Full mirroring, preparing for launch

  6. Final switch, Wikidot is read-only

  • No labels