Page MenuHomePhabricator
Create Task
Maniphest T287175

Decide on most suitable underlying technical platform
Closed, ResolvedPublic
Actions

Description

General thoughts:

  • We want well-curated content and want to keep hosted information intentionally "limited" to key documentation. (cf T290255: Workflow how to propose content changes)
  • Wikis have a focus on a low-threshold contribution workflow ("Edit" tab etc). Compared to our "normal" wikis' edit rates and content, we do not expect a high rate of changes over time.
  • We'd like to completely avoid vandalism if possible.
  • Curation on a wiki might be possible via pretty restrictive edit permissions (or in addition FlaggedRevs but see T185664 about its problems).
  • Seeing the API portal and its custom skin, I dare to say that making wikis look and behave like a mostly static site is not what wikis are designed for.
  • We ideally seek a sense of ownership for listed content. Seeing e.g. WRC at https://meta.wikimedia.org/wiki/Wikimedia_Resource_Center , I am not convinced with regard to curation and active maintenance of content there. (Plus things like T169790 haven't happened.)
  • Regarding well-curated content, we also want a certain level of standardization, machine-readability (see T276708: Define content storage format (levels, data structure, hierarchy, categorization, etc)), and translatability (not based on the Translate extension because T131516 is real, but preferably twn.net).

All of this makes me believe that MediaWiki is not the most suitable platform for a rather static Developer Portal site (cf. e.g. T67074#687573).

Thus we should explore other FOSS options, which, as a side effect, might also lower long-term maintenance costs.
(This may influence T261509: Sort out navigation concept to some extent, as MediaWiki skins also inevitably would.)

Related Objects
Search...

Event Timeline

Aklapper triaged this task as Low priority.Jul 22 2021, 3:42 PM
Aklapper created this task.
Aklapper moved this task from Inbox to Implementation on the Wikimedia-Developer-Portal board.Jul 22 2021, 4:11 PM
Aklapper added a parent task: T261510: Launch MVP of Developer Portal on https://developer.wikimedia.org/.Jul 26 2021, 1:28 PM
Aklapper mentioned this in T287498: Use standard brand colors, fonts, WM logo (Define minimum viable design).Jul 27 2021, 4:39 PM
Aklapper added a parent task: T287498: Use standard brand colors, fonts, WM logo (Define minimum viable design).
Aklapper raised the priority of this task from Low to Medium.Jul 27 2021, 4:46 PM
Aklapper raised the priority of this task from Medium to High.Aug 3 2021, 5:28 PM
Aklapper added a parent task: T289566: Sort out functional requirements related to Javascript (make sure content is available with JS disabled).Aug 24 2021, 10:55 AM
Aklapper mentioned this in T287493: Decide on In-site Search functionality (portal content itself).Aug 24 2021, 4:23 PM
Aklapper renamed this task from Sort out technical platform to Decide on most suitable underlying technical platform.Sep 15 2021, 5:44 PM
Aklapper updated the task description. (Show Details)
Aklapper mentioned this in T290254: Workflow how to add/edit content.Sep 16 2021, 3:57 PM
bd808 mentioned this in T276708: Define content storage format (levels, data structure, hierarchy, categorization, etc).Sep 16 2021, 9:39 PM
bd808 changed the status of subtask T294387: Create POC using mkdocs from Open to In Progress.Oct 26 2021, 8:22 PM
bd808 changed the status of subtask T294387: Create POC using mkdocs from In Progress to Stalled.Nov 3 2021, 8:47 PM
bd808 changed the status of subtask T294387: Create POC using mkdocs from Stalled to Open.Nov 16 2021, 11:52 PM
bd808 closed subtask T294387: Create POC using mkdocs as Resolved.Dec 6 2021, 5:56 PM
Aklapper closed this task as Resolved.Dec 6 2021, 11:35 PM
Aklapper added a project: Developer-Advocacy (Oct-Dec 2021).

Resolving this task as its subtasks are closed. Quoting T294387#7550579, we plan to use mkdocs as the base technology for generating the static site.

While wiki-style editing can be great for ease of contribution, it would have added technical overhead of setting up another wiki (and a skin) and using a wiki as a static site instead of a wiki, plus we want an element of curation with an ability to limit content as we expect content to mostly remain unchanged with only occasional updates. Furthermore, for the process of proposing and accepting content changes, a Phabricator board and patch workflow looked more feasible than setting up something like ApprovedRevs or FlaggedRevs.

• nnikkhoui subscribed.Dec 17 2021, 1:25 PM
Yaron_Koren subscribed.Dec 17 2021, 2:42 PM

It might be too late now, but are you aware of the MintyDocs MediaWiki extension (https://www.mediawiki.org/wiki/Extension:MintyDocs)? It's already in use for technical documentation at at least one company (Genesys), and, in conjunction with extensions like Cargo, Page Forms and Approved Revs, I think it provides all the structure, ownership, and control over content that is required. And, of course, it means you get to use MediaWiki. Granted, I'm the main author of all four of these extensions, so I may be biased.

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits