Talk:Community Wishlist/Wishes/Issues-based Discussion for Articles

Latest comment: 9 days ago by AdamSobieski in topic Selecting content
This page is for discussions related to the Community Wishlist/Wishes/Issues-based Discussion for Articles page.

  Please remember to:

Selecting content

edit

Hello. With respect to issues-based discussions for articles, it would be convenient to be able to detect and to visualize which selections of articles' content, if any, were mentioned in their open issues.

With such features, one could:

  1. warn editors when a planned edit was about to modify content inside of a selection relevant to one or more open issues.
  2. alert those subscribing to an open issue that its article had been modified in a way that was relevant to the issue.

One or more new templates could be used to provide these features. A template for including a selection of an article, {{Selection}}, could be used to render and visualize specified selections of content, perhaps in a manner such that selected text was surrounded by proximate text. As considered, occurrences of these templates could be readily detected in issues' wikitext.

When designing such templates, one could explore text selection models including from Web Annotations and Text Fragments.

Reasons for choosing the Text Fragments text selection model include that it readily maps to Text Fragment URLs to utilize in generated hyperlinks to articles such that selections of content are highlighted upon navigation.

If the Text Fragments model were chosen, named parameters for a {{Selection}} template would include text, textStart, textEnd and also prefix and suffix. Such a template could also have an (optional) named parameter, article, for specifying which article to make a selection from. An article parameter could be optional for templates occurring in issues as its default value could be inferred: that article which the issue was an issue for.

Such a template could, then, for example, resemble: {{Selection|textStart=...|textEnd=...}}.

As considered, such templates could render to markup involving a hyperlink containing a blockquote containing some article text around a highlighted selection of text content. That is, to something resembling:

<a href="..."><blockquote cite="..." class="outer">... lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. <span class="inner">Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</span> Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum ...</blockquote></a>

Thank you. Any thoughts on these ideas? AdamSobieski (talk) 08:15, 6 December 2024 (UTC)Reply

Thinking about it further, a {{Selection}} template could be designed for its users to be able to also manually define the outer selection of any surrounding content, in addition to being able to define the inner selection (this inner selection mapping to the Text Fragments URI of the hyperlink blockquote).
{{Selection|textStart=...|textEnd=...|outerTextStart=...|outerTextEnd...}}
If a template user did not manually specify the outer selection, the template could algorithmically select the surrounding text.
There might be yet other named parameters to enhance the {{Selection}} template. For instance, to toggle off entirely the selection of any surrounding content or to efficiently indicate for it to select any surrounding content at paragraph boundaries, at the starts and the ends of those paragraphs containing the specified selection. AdamSobieski (talk) 03:30, 7 December 2024 (UTC)Reply
@AdamSobieski thanks for sharing this wish. A couple clarifying questions.
  1. Is your definition of "issue" a selection of text in an article that could be deemed problematic, inaccurate, or biased?
  2. Could you show a couple concrete examples of the problem you're trying to solve? I think it could help illustrate the problem for others.
The solution is interesting, however I think there are a number of ways to solve for 1) surfacing articles with potential issues and 2) triaging the most important issues within an article. First, I'd like to align on which problem(s) this wish tries to solve. JWheeler-WMF (talk) 21:41, 16 December 2024 (UTC)Reply
I'm hoping that the capability to create and share selections of content would convenience issues and issue-tracking systems for wiki articles.
Presently, talk pages are utilized for collaborative tasks about articles including those in issue-based discussion threads. Also, article message boxes, or "amboxes", are presently rendered on the tops of articles to call attention to them, signaling issues with articles.
While concrete example uses for issues about articles are difficult to list exhaustively, as considered, these would include those scenarios for which "amboxes" are used: calling attention to content about an article with respect to: speedy deletion, deletion, content (neutrality, promotional), style (cleanup, need more links), notice (current event), move, and combinations of these uses, per stacking "amboxes".
As considered, content selections, including those which can provide containing contextual content, would be entirely optional for issues and could serve as clarifying examples pertinent to an issue or as evidence supporting claims made about an article, e.g., pertaining to its content or style.
Also, in theory, it might be possible to simplify UX for coordinating content selections between dynamic article content and their issues by putting the quotes in the articles instead of the issues. The quotes wouldn't render in the articles but could be uniquely identified for rendering in one or more of an articles' issue.
...lorem ipsum dolor {{selection|id=abc}}sit amet{{endselection|id=abc}} consectetur adipiscing...
...lorem ipsum dolor {{selection|id=abc|issues=123}}sit amet{{endselection|id=abc}} consectetur adipiscing...
Then, in an article's issue, e.g., issue 123, one could use a template to render a selection simply by providing its id:
...elit sed do eiusmod tempor {{showselection|id=abc}} incididunt ut labore et dolore...
With something like this, articles' editors could see where content selections were presently in use in that article's issues. AdamSobieski (talk) 21:10, 17 December 2024 (UTC)Reply

Categorizing issues

edit

In this proposed approach, articles' issues would each be URL-addressable and might each have their own wikitext resources. If so, in theory, articles' issues could each be folksonomically categorized, both manually and automatically placed into one or more categories utilizing [[Category:Name]] wikitext. Any thoughts on uses for this feature with respect to articles' issues? AdamSobieski (talk) 02:58, 7 December 2024 (UTC)Reply

edit

See Automatically showcase talk page open issues on their respective main pages and Do not fully archive unsolved issues on Talk pages.

Many or most talk page posts are issues. I think it may be better to incorporate that into the talk page but maybe doing something about the talk page such as showing a tooltip on the link to go to it saying for example "Reported issues with the article and discussion about it".

  Oppose this part In these regards, each individual issue could provide buttons for contributors to like or upvote it and to share it on social media. Wikipedia isn't some social media site and this is just canvassing for some social media hivemind irrational decision-making instead of rational constructive discussion. Things shouldn't be change this or that way because people upvote it, see WP:NOTDEMOCRACY. Forgot to mention this at our discussion at Future Audiences. Prototyperspective (talk) 12:30, 6 December 2024 (UTC)Reply

Thank you for the hyperlink to WP:NOTDEMOCRACY. Separate from any social media integration topics, there is using input buttons (e.g., "like" or "upvote") to help people to prioritize open issues. Perhaps, instead, a drop-down menu could allow contributors to express "importance" rather than "popularity". A drop-down menu could provide contributors with a list of values (e.g., "very low", "low", "normal", "high", "very high") and these, mapped to numbers, could be statistically aggregated from across populations of contributors choosing to use the menu. With some solution, in these regards, contributors viewing lists of issues could additionally sort them with respect to "priority". Also, maybe, via a new special page, contributors searching for tasks could algorithmically sort issues from collections of articles using multiple indices. What do you think? AdamSobieski (talk) 17:54, 6 December 2024 (UTC)Reply
I support the general broad idea of having issues for articles but think people should comment not vote or select priorities. Prioritization and stance can both be explained in a comment. Prototyperspective (talk) 17:59, 6 December 2024 (UTC)Reply
Ok. I removed that sentence from this item. AdamSobieski (talk) 04:03, 7 December 2024 (UTC)Reply
Great, thank you! Supporting this wish and it could substantially increase participation and quality of articles. Lots of flaws in articles are already pointed out on Talk pages but don't get looked at or fixed where having them be issues would help a lot and it would also make it easier to start contributing where you propose changes for a while and let more experienced users decide about and eventually integrate it by which one can learn more about Wikipedia editing to eventually edit articles more directly. Prototyperspective (talk) 10:58, 7 December 2024 (UTC)Reply
Return to "Community Wishlist/Wishes/Issues-based Discussion for Articles" page.