Change Details

As part of T396029, Outlines are introduced as a way to provide contextual guidance for specific types of articles that communities can define and adjust. This concept introduces new aspects that require technical exploration to identify viable approaches to implement them. Key concepts to explore are listed below: - **Type of article.** We need to consider which is the best way to represent article types in the system (Wikidata item, a Wikipedia category, [Article Topic taxonomy](https://www.mediawiki.org/wiki/ORES/Articletopic#Taxonomy), etc.). For each option, we want to identify pros and cons and determine which is the best approach to use in outlines. - **Outlines** Outlines can be defined as structured data. Technical explorations are needed to determine the best way to represent it (e.g., a JSON object), where to store them, and the implications for use and manipulation of such format and location. - **Suggested paragraph.** Representations of common paragraphs to be added include guidance content and placeholders to add references. Technical explorations can help to identify how to represent these elements in an outline, and how to render them in Visual Editor to allow the intended capabilities and a fluent editing experience. - **Verified facts from Wikidata.** Accessing data and references from Wikidata and inserting them on a specific Wikipedia is a process that we may want to explore to uncover any technical complexities. - **Community configuration.** Exploring the possibilities of the [Community configuration](https://www.mediawiki.org/wiki/Growth/Community_Configuration) platform may help to expose relevant configuration elements (outlines, supported types of topics, etc.) to the community for their adjustment.

As part of T396029, a new workflow is proposed to provide contextual guidance for specific types of articles that communities can define and adjust. This concept introduces new aspects that require technical exploration to identify viable approaches to implement them. Key concepts to explore are listed below: - **Type of article.** We need to consider which is the best way to represent article types in the system (Wikidata item, a Wikipedia category, [Article Topic taxonomy](https://www.mediawiki.org/wiki/ORES/Articletopic#Taxonomy), etc.). For each option, we want to identify pros and cons and determine which is the best approach to use in outlines. - **Outlines** Outlines can be defined as structured data. Technical explorations are needed to determine the best way to represent it (e.g., a JSON object), where to store them, and the implications for use and manipulation of such format and location. - **Community configuration.** Exploring the possibilities of the [Community configuration](https://www.mediawiki.org/wiki/Growth/Community_Configuration) platform may help to expose relevant configuration elements (outlines, supported types of topics, etc.) to the community for their adjustment. - **Visual Editor integrations.** On the initial intervention, users will reach Mobile Visual Editor with some basic support: initially preloaded contents and the inclusion of an edit tag when contents are published. We may want to explore the options to support these. # Proof of concept {F71089622, size=full} A proof-of-concept with key steps of the workflow can be useful to validate the technical exploration. The following steps are proposed: 1. **Capturing the title.** A special page where users can type the title for the new article they want to create. - **Identifying the topic and type of article.** Based on the title provided, Wikidata items are surfaced to determine whether the user is trying to create an article on any of those. If the topic is on Wikidata, the user can select it and the system will use the information to determine the related type of article. - **Choosing the type of article (when topic does not exist).** For topics that do not exist, a list is provided with the supported article types. - **Guidance message from the community.** A message defined by the community for this particular type of article. - **Guidance contents from the community.** Contents defined by the community for this particular type of article. - **Publish tag (optional).** Contents created through this workflow should include an "article-guidance" edit tag that allows further analysis. Depending on the technical complexity and cross-team dependencies, this functionality can be considered as part of a separate ticket. This is just a proof-of-concept. Some considerations: - **Simplification.** This represents a simplified set of steps and leaving aside many considerations (e.g., the article already existing, empty states, etc.). However, it puts together some of the key steps that involve the new concepts we want to explore how to support. - **Community customization.** Some steps make reference to community-defined contents. The intention for the proof of concept is to develop the support in a way that communities could provide such information (e.g., stored in a JSON file on a wiki). The actual information on the proof-of-concept can be just example placeholder information. The key point is to make it possible to update such information externally (i.e., not being hardcoded into the codebase).

As part of T396029, Outlines are introduced as a waya new workflow is proposed to provide contextual guidance for specific types of articles that communities can define and adjust. This concept introduces new aspects that require technical exploration to identify viable approaches to implement them. Key concepts to explore are listed below: - **Type of article.** We need to consider which is the best way to represent article types in the system (Wikidata item, a Wikipedia category, [Article Topic taxonomy](https://www.mediawiki.org/wiki/ORES/Articletopic#Taxonomy), etc.). For each option, we want to identify pros and cons and determine which is the best approach to use in outlines. - **Outlines** Outlines can be defined as structured data. Technical explorations are needed to determine the best way to represent it (e.g., a JSON object), where to store them, and the implications for use and manipulation of such format and location. - **Suggested paragraph.** Representations of common paragraphs to be added include guidance content and placeholders to add references.Community configuration.** Exploring the possibilities of the [Community configuration](https://www.mediawiki.org/wiki/Growth/Community_Configuration) platform may help to expose relevant configuration elements (outlines, Technical explorations can help to identify how to represent these elements in an outlinesupported types of topics, and how to renderetc.) to them in Visual Editor to allow the intended capabilities and a fluent editing experience community for their adjustment. - **Verified facts from Wikidata.** Accessing data and references from Wikidata and inserting them on a specific Wikipedia is a process that wisual Editor integrations.** On the initial intervention, users will reach Mobile Visual Editor with some basic support: initially preloaded contents and the inclusion of an edit tag when contents are published. We may want to explore to uncover any technical complexitieshe options to support these. # Proof of concept {F71089622, size=full} A proof-of-concept with key steps of the workflow can be useful to validate the technical exploration. The following steps are proposed: 1. **Capturing the title.** A special page where users can type the title for the new article they want to create. - **Community configuration.** Exploring the possibilities of the [Community configuration](https://www.mediawiki.org/wiki/Growth/Community_Configuration) platform may help to expose relevant configuration elements (outlinesIdentifying the topic and type of article.** Based on the title provided, Wikidata items are surfaced to determine whether the user is trying to create an article on any of those. If the topic is on Wikidata, the user can select it and the system will use the information to determine the related type of article. - **Choosing the type of article (when topic does not exist).** For topics that do not exist, supported types of topics,a list is provided with the supported article types. - **Guidance message from the community.** A message defined by the community for this particular type of article. - **Guidance contents from the community.** Contents defined by the community for this particular type of article. - **Publish tag (optional).** Contents created through this workflow should include an "article-guidance" edit tag that allows further analysis. etc.) to the community for their adjustmenDepending on the technical complexity and cross-team dependencies, this functionality can be considered as part of a separate ticket. This is just a proof-of-concept. Some considerations: - **Simplification.** This represents a simplified set of steps and leaving aside many considerations (e.g., the article already existing, empty states, etc.). However, it puts together some of the key steps that involve the new concepts we want to explore how to support. - **Community customization.** Some steps make reference to community-defined contents. The intention for the proof of concept is to develop the support in a way that communities could provide such information (e.g., stored in a JSON file on a wiki). The actual information on the proof-of-concept can be just example placeholder information. The key point is to make it possible to update such information externally (i.e., not being hardcoded into the codebase).