Page MenuHomePhabricator

Ability to watch section levels of pages
Open, LowestPublic

Tokens
"Doubloon" token, awarded by ToBeFree."Like" token, awarded by Liuxinyu970226."Doubloon" token, awarded by Nemo_bis."Like" token, awarded by Dan_Eisenberg."Doubloon" token, awarded by Dalba."Like" token, awarded by Fixuture."Mountain of Wealth" token, awarded by RandomDSdevel."Like" token, awarded by Kozuch.
Assigned To
None
Authored By
bzimport, Oct 18 2004

Description

Author: sundarbecse

Description:
I would love to be able to watch sections of a page instead of whole articles, particularly for pages
like [[Reference Desk]]. Otherwise, pertinent changes to sections that interest me get superceded by
subsequent changes to other sections.


Further details: Helpful for e.g. notability or deletion discussions. Also helpful in case a whole section gets removed or in case of long articles where it's difficult to recognize fast which section was edited.

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 45 support votes, and was ranked #18 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Watchlists#Section_watchlists

Also proposed in Community-Wishlist-Survey-2016. Received 35 support votes, and ranked #43 out of 265 proposals. View full proposals with discussion and votes here.

This issue was also voted into the top 20 requests of the de-wiki community in 2013

Details

Reference
bz738

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

(In reply to comment #19)

Shorter comments (or structured text with paragraphs and sub-headings) on
technical aspects highly welcome - note that this is not a forum. Thanks :)

Sorry! I'll keep a better eye on my posts' lengths in the future, but that was a kind of 'train of thought' post that I guess people try to avoid around here. But, returning to the post in question, have you actually read it?

Alsee added a comment.Sep 18 2014, 2:25 PM

This can be implemented as a filter on page watchlisting. A section begins at the first character of the section-title, the section ends at the last non-whitespace character before the next *equal level* section title (or the end of page). Any edit that adds, removes, or alters even one character in this region counts as a watched-edit. Any edit that touches the section title itself is a watched edit. Special case: If a section title is modified into a new valid section title then the watchlisting should be updated to follow the new section title. An edit that creates or modifies a subsection will be seen because the defined section only ends at the next *equal level* section. An edit that creates a new equal-level section after the watched section will not be watched, it is clearly outside the filter-zone I defined.

This bug/enhancement has only a few votes, but there's no doubt it would be widely valued.

Interesting new thought: A page watch that notifies you *only* of new section titles. This has various uses. It's a great way to follow Village Pump or Articles For Deletion of other process-pages. It's a great way to set aside articles-of-interest and only jump in when an important/interesting new Talk topic appears.

I think there are multiple degrees of complexity / steps possible here.
The simplest/crudest way possible is probably

  1. add a "watch" / "unwatch" button next to the "edit" button of each section, which stores the header text as is in the user's watchlist,
  2. let users edit that text match freely in Special:EditWatchlist,
  3. show in Special:Watchlist only the edits whose summary matches that section text, similar to how we filter by minor/bot/etc. edit.

Of course this would cover only a subset of the cases, but potentially a significant one. Anyone bothers to search in Google Scholar or whatever if there's some relevant past research on section editing?

Nemo_bis set Security to None.

This would be very useful! Had the same idea - glad to see it already being filed here. It's really inconvenient to have to watch a whole page if you just want to get notified at changes of a specific section. Eventually this would actually lead to more people watching more pages and that more efficiently. Hence it might lead to a significant improvement of Wikipedia's quality. Among many other things it would also be useful for talk pages & meta discussions fostering more & better discussion there.
-> It allows people to more efficiently watch more pages.
So I really hope for this to get solved at some point.

Eventually one would have to go for another approach than what is used for article-differences right now. After all it probably comes down to:
a) splitting the old document into sections (syntactically)
b) comparing whether the differences to the new html document include parts within the watched section
c) recognizing renamings of the section when the comparison detected the name of the watched section of the old document in b) but not in the new document

Qgil added a comment.Mar 7 2015, 9:06 PM

I'm still missing credible examples of articles (not discussion pages)
where this feature would be so badly needed and so popular as to refactor
MediaWiki page structure. With the current = sections any implementation
would be too fragile, for the reasons explained above.

I keep thinking that Brion did well declining this task year ago. Flow is
covering the need of this original and all the duplicates, which focused in
discussion pages.

so badly needed and so popular as to refactor MediaWiki page structure.

Judging the use case from the difficulty of one proposed implementation is not particularly helpful, IMHO.

It's not that difficult to find examples of the use case: just find a busy page from the wikistats zeitgeist, check its history:

MariaDB [cawiki_p]> select rev_comment, count(rev_comment) as comments from revision where rev_page = 309 group by rev_comment order by comments DESC limit 10 ;
+---------------------------------------------------------+----------+
| rev_comment                                             | comments |
+---------------------------------------------------------+----------+
|                                                         |      441 |
| /* Enllaços externs */                                  |       66 |
| /* Districtes i barris */                               |       54 |
| /* Ciutats agermanades */                               |       30 |
| /* Esdeveniments */                                     |       29 |
| /* Clima */                                             |       26 |
| /* Ciutats agermanades i convenis de col·laboració */   |       26 |
| /* Política */                                          |       19 |
| /* Geografia */                                         |       17 |
| /* Esport */                                            |       17 |
+---------------------------------------------------------+----------+
10 rows in set (0.01 sec)

As a user interested in external links spam/clima/política/geografia/esport, I want to contribute to the relevant section of an article and follow updates to that section, without being bothered by all the useless quarrels of the editors interested in [other thing].

Alsee added a subscriber: Alsee.Nov 17 2015, 12:47 PM

Why is this listed as blocked by T38340? The presence or absence of opposite-direction text should be irrelevant to detecting that text is unchanged.
Note: This feature is on the list of projects being considered for the Community Tech team.

http://bugs.wmflabs.org/show_activity.cgi?id=738 said:

mah 2012-05-01 21:03:57 UTC Depends on 36340

Seems a mistake indeed.

Menner added a subscriber: Menner.Nov 19 2015, 7:00 PM

The diff algorithm does already evaluate context information[1]. Why not collection context information about sections while creating a diff. It is not uncommon as gnu pages say[2]. In a second step this information can be used by the watchlist code to evaluated observed section. At best give the whole section context like: == H1 === H2 ==== H3

Using the wiki syntax '==' and '===' isn't fragile since wiki syntax is the pillar of Mediawiki, also it has a minor pitfall about invariance. In doubt such changes can be high lighted diffrently in the watchlist.

The section context would be also useful for diff pages. We are using diff for that long and havn't adopted it for our purposes ever. Isn't that odd?

[1] https://en.wikipedia.org/wiki/Help:Diff
[2] https://www.gnu.org/software/diffutils/manual/html_node/Sections.html

PS:

We are using diff for that long

Who is "we"? Wikimedia wikis don't use GNU diff but wikidiff2.

Dalba awarded a token.Nov 30 2015, 9:08 PM
He7d3r added a subscriber: He7d3r.Dec 1 2015, 11:19 PM
Scott added a subscriber: Scott.Dec 3 2015, 11:23 AM
IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.
DannyH updated the task description. (Show Details)Feb 5 2016, 11:51 PM

Two questions:

  1. Is this task about any pages (as StructuredDiscussions on talk/discussion pages offers watching a specific section / topic, so technology already exists but outside of the MediaWiki core), or rather about articles in the main namespace as described in T2738#1098527 ?
  1. Is the situation described by Brion twelve years ago in T2738#34503 still the current status or is the Parsing-Team working on technology that might overcome this?:
In T2738#34503, brion wrote:

Sorry, but this is not practical; sections don't have a consistent identity which could be watched reliably.

This is about standard wikitext pages

Question still open:
Is the situation described by Brion twelve years ago in T2738#34503 still the current status or is the Parsing-Team ( @ssastry? @cscott? @Legoktm? or someone else?) working on technology that might overcome this?:

In T2738#34503, brion wrote:

Sorry, but this is not practical; sections don't have a consistent identity which could be watched reliably.

I already answered this question:

I think there are multiple degrees of complexity / steps possible here.
The simplest/crudest way possible is probably

  1. add a "watch" / "unwatch" button next to the "edit" button of each section, which stores the header text as is in the user's watchlist,
  2. let users edit that text match freely in Special:EditWatchlist,
  3. show in Special:Watchlist only the edits whose summary matches that section text, similar to how we filter by minor/bot/etc. edit.

Of course this would cover only a subset of the cases, but potentially a significant one. Anyone bothers to search in Google Scholar or whatever if there's some relevant past research on section editing?

Nemo_bis rescinded a token.Jul 16 2016, 8:00 AM
Nemo_bis awarded a token.

search in Google Scholar or whatever if there's some relevant past research on section editing?

I found nothing. Perhaps someone else might have better luck.

matej_suchanek removed a subscriber: wikibugs-l-list.

Question still open:
Is the situation described by Brion twelve years ago in T2738#34503 still the current status or is the Parsing-Team ( @ssastry? @cscott? @Legoktm? or someone else?) working on technology that might overcome this?:

In T2738#34503, brion wrote:

Sorry, but this is not practical; sections don't have a consistent identity which could be watched reliably.

Yes, his comment is still true (there's a bug about stable ids for sections somewhere) but I think Nemo's implementation suggestion is probably the best way to go forward for now.

Nemo_bis added a comment.EditedOct 2 2016, 10:30 AM

Yes, his comment is still true (there's a bug about stable ids for sections somewhere) but I think Nemo's implementation suggestion is probably the best way to go forward for now.

I think the UI for the basic version is rather straightforward (more controls and assorted improvements can be done later). Is the next step to propose a possible DB schema? Are there other potentially controversial aspects or blockers?

Maybe want to check how frequent edit summaries satisfy/don't satisfy the criteria in T2738#34571 so that we know how robust that fix is.

I think the UI for the basic version is rather straightforward (more controls and assorted improvements can be done later). Is the next step to propose a possible DB schema? Are there other potentially controversial or blocking?

Probably. It needs coordination with the other planned schema changes to watchlist (@Addshore?). We would also need some kind of index on rev_comment. I don't know how expensive or problematic that would be. It could also be implemented like the category watchlist stuff was potentionally?

Qgil removed a subscriber: Qgil.Oct 4 2016, 6:50 PM
This task was proposed in the Community-Wishlist-Survey-2016 and in its current state needs owner. Wikimedia is participating in Google Summer of Code 2017 and Outreachy Round 14. To the subscribers -- would this task or a portion of it be a good fit for either of these programs? If so, would you be willing to help mentor this project? Remember, each outreach project requires a minimum of one primary mentor, and co-mentor.
Liuxinyu970226 awarded a token.
Lea_WMDE updated the task description. (Show Details)Mar 9 2018, 12:11 PM
Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 28 2018, 11:22 PM
ToBeFree rescinded a token.
ToBeFree awarded a token.
Catrope moved this task from Inbox to External on the Growth-Team board.Aug 20 2018, 11:02 PM

I know this has been open for ages, but would it be feasible for a tag (the same as existing tags, or a different sort so they also contain the section name) to be auto-associated with an edit if said edit is made by clicking a section edit link? Then the "watch a section" functionality wouldn't have to rely on parsing, and could filter out all edits that have an unrelated tag. Regex matching could also be possible with such an implementation (e.g. if someone wants to be notified about Tech News without publicly announcing their subscription).

Such a filter would also catch edits made in sections with the same name and edits to the whole page (i.e. edits without tags), but it would filter out the majority of unrelated edits.

(Obviously there would be issues with templates being used in section names and section names being changed, but those things already break current edit summaries.)

Oh, this is basically the same as T2738#34571. Adding a tag would allow some auto-filtering (e.g. removal of templates), though.