Last modified: 2009-07-06 01:37:22 UTC
Mediawiki should have a way to watch a single section of a large article. For
talk pages and pages like Wikipedia's Village Pump and Reference Desk, it's
often the case that a user only cares about a single section. Trying to keep up
with that section by watching the entire page is impractical, as a large number
of edits may be made to the page in other sections, which the user doesn't care
about. This creates both false positives (as the user investigates a change
only to find it wasn't to his section) and false negatives (as the user doesn't
notice a change to his section due to another edit shortly after).
Additionally the time between addition and archiving on some of these pages may
be low enough that the user returns in a few days to see if there are any
responses, only to have lost the section to the archiving system. It would
therefore be optimal to have moved sections retain the list of users watching
them, or failing that, for the user to be able to quickly determine who removed
a section and navigate to that point in their edit history, since the addition
to the archive should be nearby. The first method would probably require adding
a move section feature, while the second is just a slight expansion of the
watchlist (and possibly the user contributions), provided that the user was able
to watch a section and not the entire article.
Not possible with the current database infrastructure; would require new columns
to be added to recentchanges, watchlist, and possibly revision, not to mention
treating sections with more significance than we currently do. Precedent of
other bugs, e.g. bug 8955 indicates we may not want to afford sections this
These problems are basically the ones that LiquidThreads (bug 1234) addresses.
Section watching is not a good solution to the essential problem that sections
are not a good way to represent threads of discussion.
I agree with Simetrical's assessment. Marking this as a duplicate of #1234.
*** This bug has been marked as a duplicate of 1234 ***
*** This bug has been marked as a duplicate of bug 738 ***