From Test-Scratch-Wiki

m
m (repository has been deleted)
 
Line 1: Line 1:
{{delete|moved to https://github.com/InternationalScratchWiki/development-meta/wiki/Development-Workflow}}The Scratch Wiki ecosystem runs on [[wikipedia:MediaWiki|MediaWiki]] with a large number of [[mw:Manual:Extensions|extensions]] and a custom [[mw:Manual:Skins|skins]]. Some have been created and bundled with MediaWiki, others were created specifically for use on Scratch Wiki. A few outliers have been created by third parties as well. This page specifically refers to the development process for software development on Scratch Wikis
+
The Scratch Wiki ecosystem runs on [[wikipedia:MediaWiki|MediaWiki]] with a large number of [[mw:Manual:Extensions|extensions]] and a custom [[mw:Manual:Skins|skins]]. Some have been created and bundled with MediaWiki, others were created specifically for use on Scratch Wiki. A few outliers have been created by third parties as well. This page specifically refers to the development process for software development on Scratch Wikis
  
 
==Terminology==
 
==Terminology==

Latest revision as of 05:25, 4 October 2021

The Scratch Wiki ecosystem runs on MediaWiki with a large number of extensions and a custom skins. Some have been created and bundled with MediaWiki, others were created specifically for use on Scratch Wiki. A few outliers have been created by third parties as well. This page specifically refers to the development process for software development on Scratch Wikis

Terminology

In this article, the term "software" refers to both extensions and skins (but not other software such as bots).

Fundamental Principles

Software development is guided by a number of fundamental principles, including:

  • In general, the MediaWiki core should not be modified directly. All additional functionality should be provided through extensions and skins.
  • Security should always be the highest priority

GitHub

All custom built software belongs to the InternationalScratchWiki GitHub organization, with some legacy exceptions.

Access

All GitHub organization owners have access to all repositories. Additionally, contributors for individual software components may request write access to the corresponding repository. Those without write access may fork a repository to their own account and submit pull requests with proposed changes.

Creating New Repositories

If you are not a GitHub organization owner and wish to create a new piece of software, please contact a GitHub organization owner and ask them to create one for you. Also provide the GitHub account of any users that will be contributing so they can be given write access.

Automated Deployment

Some repositories, and all new repositories that will be created going forwards, support automated deployment. This allows updates posted to GitHub to be applied to the server as soon as they are available on GitHub. Note that this process is not automatic, but may be run by any GitHub organization owner at any time.

Git procedures

Branches and Pull Requests

Code on the master branch should be considered ready to be deployed to production (or ready to be deployed to staging if the extension is still under development). Any in-progress code should be put in its own branch created for the specific work item being accomplished (bug to be fixed or feature to be added). Once the work item is considered complete, the developer for that branch should submit a pull request, at which point a core developer will review the code and decide whether or not to accept the proposed changes. Newer repositories are protected so that their primary branch cannot be directly committed to nor merged with except by a core developer, though core developers are still strongly recommended to have someone review their code whenever possible.

Staging Wiki

When a piece of software is under development or an improvement is being developed, it may be deployed to the Staging Scratch Wiki, which is available at https://staging.scratch-wiki.info.

Security Concerns

In the case that a significant security vulnerability is identified with a piece of software, a core developer should be notified privately, and the issue should not be discussed publicly until it is resolved. Additionally, "penetration testing" (i.e. abusing a vulnerability to either test or demonstrate it) should not be performed more than absolutely necessary (and when possible, please do not perform any at all and instead notify a core developer explaining the situation so they can perform the testing in a safe manner). If the issue is deemed to be due to a shortcoming in an extension, a GitHub security advisory may be issued. If the extension is not managed by International Scratch Wiki, the extension may be temporarily removed until the vulnerability is resolved.

Cookies help us deliver our services. By using our services, you agree to our use of cookies.