We need to document our various coding styles for:

• Javascript
• Markdown
• CSS
• JSX

We should also provide appropriate linting and related tools where possible.

Part of this work is covered by #40 but we need to turn this into a written coding style to make it easier to understand.

The URL of the page on https://docs.moodle.org/dev/

https://docs.moodle.org/dev/Plugin_contribution

Is this documentation specific to a Moodle version?

No

What location would you suggest in the new docs?

There are several pages associated with https://docs.moodle.org/dev/Plugin_contribution, like https://docs.moodle.org/dev/Plugin_types or https://docs.moodle.org/dev/Plugin_contribution_checklist).

I would suggest adding most of them to /general/development/plugins/ but link them all inside Guides/Developer guides/Plugins :-)

Migrate all historic meetings at https://docs.moodle.org/dev/Developer_meetings
This will involve determining the best format for them, perhaps including a custom jsx component for the table?

Don't forget to grab any files included as part of each meeting.

The URL of the page on https://docs.moodle.org/dev/New_feature_ideas

New_feature_ideas

Is this documentation specific to a Moodle version?

No

What location would you suggest in the new docs?

I think this information should be placed as a section in the general/development/new-features-ideas.md (probably will need to adapt part of the text to avoid repetitions).

** Which page on https://docs.moodle.org/dev needs to be migrated?**

https://docs.moodle.org/dev/Themes

** Does this page need documentation specific to a Moodle version? **

Yes

** Where do you think it should be placed? **

• /docs/apis/themes

** Which page on https://docs.moodle.org/dev needs to be migrated?**

https://docs.moodle.org/dev/Enrolment_plugins

** Does this page need documentation specific to a Moodle version? **

Yes

** Where do you think it should be placed? **
/docs/api/enrol

What do we need to do?

Page /general/development/policies/security/session-fixation is incomplete. It would be great fill-in missing sections :-)

** Which page on https://docs.moodle.org/dev needs to be migrated?**

https://docs.moodle.org/dev/Repository_plugins

** Does this page need documentation specific to a Moodle version? **

Yes

** Where do you think it should be placed? **
/docs/apis/plugintypes/repository

What do we need to do?

Create a job to parse the data/migratedPages.yml file and check that the routes are up-to-date and point to a valid location.

What is the Moodle feature that needs documenting?

This is partially already implemented in /docs/tools but it needs to move out of there.

I'd suggest it should be in /general/development/tools and have it's own navbar link perhaps.

We need to document:

• MDK - #54
• Our PHP code sniffs - #54
• moodle-plugin-ci
• Our official docker images
• grunt, eslint, stylelint, and friends
• CiBoT

We may also want to consider documenting the following under tools:

• PHPUnit
• Behat

Is this documentation specific to a Moodle version?

No

Are you able to provide a patch for this?

Yes - I will create one

For links to the Moodle Academy we need to improve, and find a way to maintain the metadata.

@jgramp has suggested that we should also add:

• Estimated completion time (e.g. 4 hours, 2 days, 1 week)
• Level (Beginner to Advanced)

I wonder whether we can have this json generated on the Moodle Academy, with the above fields set as Course custom fields. If Academy can define these as custom fields, and then provide us with a PHP endpoint to generate the JSON content, then we can fetch this periodically (i.e. every sunday or on manual request) and commit it to the repository, and then use it during builds.

The URL of the page on https://docs.moodle.org/dev/

https://docs.moodle.org/dev/Integration_Review

Is this documentation specific to a Moodle version?

No

What location would you suggest in the new docs?

general/development/process/integration-review.md

The URL of the page on https://docs.moodle.org/dev/

https://docs.moodle.org/dev/Testing

Is this documentation specific to a Moodle version?

No

What location would you suggest in the new docs?

general/development/process/testing.md

Apart from that page, there are other pages related to Testing that might be migrated together:

• https://docs.moodle.org/dev/Testing_of_integrated_issues
• https://docs.moodle.org/dev/QA_testing
• https://docs.moodle.org/dev/Testing_instructions_guide
• https://docs.moodle.org/dev/Acceptance_testing

** Which page on https://docs.moodle.org/dev needs to be migrated?**

https://docs.moodle.org/dev/Authentication_plugins

** Does this page need documentation specific to a Moodle version? **

Yes

** Where do you think it should be placed? **

• /docs/apis/auth
• /docs/apis/plugintype-auth

This is for the plugintype, not the API.

We should work with Jess Gramp (@jgramp) and Rajneel to work out how best to link from the Developer resources to the development courses in the Moodle Academy.

From a User Experience perspective it would be good to have:

• A navbar element
• A landing page explaining that courses are available and linking to a landing page on the Academy

What do we need to do?

During a QA cycle
We should include a Front page feature which links to the QA details and joining the QA cycle

** Which page on https://docs.moodle.org/dev needs to be migrated?**

https://docs.moodle.org/dev/Filters

** Does this page need documentation specific to a Moodle version? **

Yes

** Where do you think it should be placed? **
/docs/api/plugintype-filter

We should look at using https://github.com/errata-ai/vale, and there are some great writing guides which we may want to adopt. These are detailed at https://github.com/errata-ai/styles

I'd suggest we look at one or more of:

• Alex as a Vale ruleset
• Proselint as a Vale ruleset
• Microsoft
• Google
• Write-good
• Readability

This is related to #48 but they have different remits.

We need to move this repo to the moodlehq organisation and set it all up as appropriate.

We need to determine the most appropriate repository name for this.

As part of the migration we need to:

• create a new template on the legacy docs pointing to the new doc
• update code to use this new template as we migrate docs
• mark the docs are read-only
• mark any docs which we do not plan to migrate as obsolete + read-only

What do we need to do?

Fetch some contributor lists to use as cspell dictionaries. We probably want to do a few other lists too.

We can do these as a weekly pull request similar to the obsolete pages job, or even do it all in a single job.

What is the Moodle feature that needs documenting?

We should make sure that:

• we have a code of conduct
• we have all read it
• require that it be signed for contributions?

As far as I'm aware we don't really have a code of conduct at the moment. We do have a Forums code of conduct for taking part in the Moodle forums, but it is out-dated and does not apply clearly to this project.

One CoC that we may want to consider adopting is the Contributor Covenant (https://www.contributor-covenant.org/), which is widely used within the Open Source community.

Is this documentation specific to a Moodle version?

No

Are you able to provide a patch for this?

No (Default)

What is the URL of the page?

general/development/process/qatesting.md

What is the issue with this page?

We should change references from contact Helen to contact the QA team and turn them into a link with instructions on how to contact Helen (i.e. create a new issue?).

Pinging @wildgirl to know the best way to proceed here.

Are you able to provide a patch for this?

Yes - I will create one

What is the Moodle feature that needs documenting?

We have a placehodler for a quick start in /docs/gettingstarted/quickstart

It would be great to get some good quick start docs.

Is this documentation specific to a Moodle version?

Unsure (Default)

Are you able to provide a patch for this?

No (Default)

What do we need to do?

We're currently trying to acquire https://moodle.dev, which is currently squatted. This may take some time.

In the mean time, it would be good to have some more identity that github.io. I have a few suggestions, all of which are currently available for a reasonable cost:

• learnmoodle.dev
• learnmoodle.io
• moodledev.io
• moodledev.info
• moodle.sh
• moodle.how
• moodle.fyi
• moodledev.how
• moodledev.fyi
• moodle.wiki

Any thoughts?

What do we need to do?

On metadata you can specify a title that will be displayed in 3 places:

• Sidebar / menus
• HTML head title tag.
• Level 1 title on page.

If you want the title from sidebar and level 1 differ, you have to write a new level 1 title using a single hash, but then the linter warns you.

What do we need to do?

Identify documents in various state in the front-matter and turn this into a page banner with links to contributing to docs, etc.

For example:

---
title: Question bank
draft:
  issueNumber: 99
  trackerIssue: MDL-12345
tags:
  - draft
---

Could be turned into a banner which links to the devdocs issue with information, and the Tracker issue (if relevant), and provides links to the devdocs contributing docs, etc.

Similarly a Draft tag could warn users that this page is a draft and may not be complete, and to see issue # for more information or provide feedback.

As part of the branding, we need to determine the brand, domain, and hosting solution for the new site.

I'd propose that we go for: https://develop.moodle.org

We may need to use a different TLD to ensure that there is no possibility for malicious content (not 100% sure here) but @ mickhawkins may have thoughts on the topic.

As well as the host name, we need to determine any branding that goes with it, as well as colour schemes.

Finally we need to determine the optimum hosting of the content.

For now I'd suggest that we may want to go with Github Pages and us their CNAME hosting option.

What do we need to do?

Move the app docs out of the docs directory into its own location.

What do we need to do?

Suggestion after discussion with Eloy.

We already track a list of migrated pages in the migratedPages.js file.

At the moment we manually edit the legacy docs to add the Template link after an issue is merged.

What we could look to do is, for any page which has been migrated:

• use the WikiMedia API to set the {{Template:Migrated|newDocId=/path/to/new/doc}}
• Protect the page from further changes.

This would allow us to reduce steps in the migration, and would allow us to restructure pages in the new docs and have the Migration links continue to work.

The WikiMedia API should support these changes.

This issue is about importing the list of web services in each Moodle release and pulling them in to the dev docs as a JSON file which we can render to devdocs.

This could then be extended to add searchability, and show other metadata where possible.

Perhaps the WS docs can also be pulled in?

Currently displayed in a few places, including https://docs.moodle.org/dev/Frankenstyle

What do we need to do?

We can do this in two way:

• query the tracker for all qa assignees
• query Moodle for the list of users holding the badge

** Which page on https://docs.moodle.org/dev needs to be migrated?**

https://docs.moodle.org/dev/Course_formats

** Does this page need documentation specific to a Moodle version? **

Yes

** Where do you think it should be placed? **
docs/apis/course-formats

The URL of the page on https://docs.moodle.org/dev/

Component_library

Is this documentation specific to a Moodle version?

No

What location would you suggest in the new docs?

/general/development/tools/component-library.md

Migrate https://docs.moodle.org/dev/Activity_modules

Proposed to: /docs/plugintypes/mod but possibly under /docs/apis/plugintypes/mod ?

The URL of the page on https://docs.moodle.org/dev/

https://docs.moodle.org/dev/Admin_settings

Is this documentation specific to a Moodle version?

Unsure (Default)

What location would you suggest in the new docs?

What about /docs/apis/other/admin-settings.md ? A new category (Other) could be created inside API guides, to place pages that are not strictly plugin types or subsystems

Include from Moodle as build step from shell script.

See MDL-74391 for suggestion to migrate them to markdown. Aim to do this early in 4.1 cycle.

The frontpage component has space to highlight a number of core features.

We need to decide what these features should be, and then work with Marketting to get appropriate iconography.

We also need to determine the best ordering for these.

The URL of the page on https://docs.moodle.org/dev/

https://docs.moodle.org/dev/File_API

Is this documentation specific to a Moodle version?

Yes

What location would you suggest in the new docs?

/docs/api/files/index.md

We need to migrate:

• File_API #59
• FIle_API_internals #59
• Using_the_File_API_in_Moodle_forms

These should all be a part of the /docs/api/files subtree

What is the Moodle feature that needs documenting?

We need to write:

• CONTRIBUTING.md
• Something in the actual docs, maybe under Community

Is this documentation specific to a Moodle version?

No

Are you able to provide a patch for this?

No response

What do we need to do?

There's a few APIs we can use:

• https://docs.moodle.org/400/en/Special:ApiSandbox#action=query&format=json&list=allusers&auprop=editcount&aulimit=max&auwitheditsonly=1
• https://docs.moodle.org/400/en/Special:ApiSandbox#action=query&format=json&list=users&usprop=groups%7Ceditcount%7Cgender&ususers=andrewnicols

Netiher are great and will take a lot of work to do.
Sadly none of those APIs are in the nodemw implementation (https://github.com/macbre/nodemw).

https://github.com/wataru-chocola/remark-definition-list

Currently blocked by facebook/docusaurus#6520

What is the URL of the page?

docs/guides/moodleapp/app-in-browser

What is the issue with this page?

Help wanted!

Use app in browser documentation has only been tested on Linux. If you are using a different operative system tell us here how it went to improve the docs.

Are you able to provide a patch for this?

No response

What is the Moodle feature that needs documenting?

Moodle Icon requirements for:

• general plugin icons
• activity icons

Is this documentation specific to a Moodle version?

Yes

Are you able to provide a patch for this?

No (Default)

What do we need to do?

While reviewing #87, Andrew suggested that with the libraries we should:

• update the existing thirdpartylibs.xml files in core and add:
  • whether customisations have been made (<customised /> if true)
  • the URL source of the library
  • the copyright owner
• create a script to parse the various thirdpartylibs files and turn them into markdown
• turn that into a Github action run weekly

We should add templates for:

• Migrating documentation from the legacy site
• Creating new documentation
• Chores (like updating dependencies, etc.)
• Reporting bugs in documentation
• Reporting bugs in the system

The URL of the page on https://docs.moodle.org/dev/

XMLDB_editor

Is this documentation specific to a Moodle version?

No

What location would you suggest in the new docs?

/general/development/tools/xmldb.md

BTW, https://docs.moodle.org/dev/XMLDB_defining_an_XML_structure should also be reviewed to see whether it's possible to include it on the same page or not.

** Which page on https://docs.moodle.org/dev needs to be migrated?**

https://docs.moodle.org/dev/Blocks

** Does this page need documentation specific to a Moodle version? **

Yes

** Where do you think it should be placed? **
Either:

• /docs/apis/blocks
• /docs/apis/plugintypes/blocks
• /docs/plugintypes/blocks

What do we need to do?

While reviewing #87, Andrew raised this idea:

• We can auto-generate the user doc contributions using the Wikimedia API (https://docs.moodle.org/dev/Special:ApiSandbox#action=query&format=json&list=allusers&continue=-%7C%7C&aulimit=max&auwitheditsonly=1)
• We can also easily generate the list of Dev docs contributors with: git shortlog -sn