Talk pages consultation 2019/Phase 2 community discussion summaries

Jump to navigation Jump to search

On this page are summaries from the different communities that participated in Phase 2 of the talk pages consultation. Please don't edit other participants' summaries (except to fix typos).


What is a community summary?

The goal of a community summary is to wrap up the discussions and provide a summary of what your participants said. That way, other communities can learn about your community's needs, concerns, and ideas. We have seen very different feedback on different wikis, and it is time to discover what everyone thinks!

Please include in that summary:

  • every perspective or idea your community had, and
  • how frequent each idea was; for example,
    • how many users shared a given opinion
    • whether an idea was more common among different types of contributors (newcomers, beginners, experienced editors...)

You can add as much detail as you want in that summary.

Can't the Wikimedia Foundation read all the feedback?

We are trying, but we really need your help. For most conversations, we have to use machine translation, which has limitations. This can help us find the most common needs or global ideas. Machine translation is useful, but it does not tell us how people are feeling or what makes your community unique.

Your community summary should be built from your community's perspective, experience and culture. You might also know of relevant discussions in other places, which we did not find (for example, perhaps someone left a note on your user talk page – it is okay to include that!). Your summary is extremely important to us.

What are the next steps?



Czech community[edit]

  1. The community discussion participants overall agree with the proposal. It could be challenging for the developers, but the automatic features are considered super-helpful by several participants, especially for older/technical-unexperienced wiki users.
  2. There is a positive attitude towards any wikitext/behavioral changes between the participants too. Overall this will be done automatically by the editor, right? Several participants mentioned the new system would save much time, make things easier and make it more clearly arranged, so any markup/behavior changes are completely for a good purpose.
  3. This question was the first dispute in Phase 2. Each person has its own opinion where the talk link should be placed. Mostly they supported to leave the link as is. The discussion is important maybe as much as the article itself. Websites usually have the talk under the contents, but this approach could attract internet trolls. There are several people mentioning a link to talk for every article section, but several others were opposing this idea. The reason against should be a user (especially a newcomer) could be flooded/overloaded by so many UI features/links, that (s)he easily overlooks the other UI features. This could also be a reason newcomers can't see the current talk page link! They are just visually flooded/overloaded with other UI features. Also it was mentioned readers are mostly not interested in talk, so they shouldn't be disturbed by such link.
  4. Although this is technically possible and can make developing and/or administration easier, several participants mentioned quite important problems with this approach. First, move like this would break Wikidata connections between major talk pages (Village pumps, RfCs, etc.). Several others also mentioned this could break the connection page-talk. Community talk pages (Village pump, RfCs, etc.) sometimes also need talk pages about themselves. As a workaround there were suggested two approaches: a page metadata similar to content model, or a magic word similar to the current __NEWSECTIONLINK__. The Project namespace also makes the page more striking. This would be a major intervention to the current scheme just for such a few pages. Some pages also don't have any distinguishable line between talk and content (usually WikiProject ones).
  5. All participants were positive about seeing/watching a history of just one thread they're interested in in the whole page, because it does really save the time. But also the whole page history is required. But there were various thoughts, that the whole page history does not need to be "standard". For example, the whole page history could feature just thread moves/creations/archivations + the timestamp of the last post + changes since last seen (in a watchlist). Interestingly this makes the third option to the rulette: users should be able to watch only one selected thread, all threads in the page, or a thread actions in the page. Simultaneously and separately. This seems as a good challenge for developers, but for a good prize. Moreover, from the whole page history all the move/archive/hide/fully delete (sysop anti-spam patrol)/lock/search/filter thread tools could be accessible.
    Several participants mentioned this could be achieved using subpages easily, there already is a technical background (move/rename/delete/API tools) for this option, the whole page history would also be working from the beginning, just the all-threads-in-page history would need to be compiled by software. There was a concern about the name of the subpages/threads, which should be human-readable (mainly because of patrol), but also easily auto-generated. Perhaps these could be borrowed from Growth's help panel?
    There were minor concerns about automatic mass messages for users. These sections should ideally be separated from the main user talk. Perhaps some separate user page to catch these messages, or one whole-community page, which would ping the subscribed users for each new thread.
  6. At this point there were two groups of opinions. Several people would separate the banners into the action=info page, history page, or even to the new namespace. The others think there is no need to split these parts. The banners could be also guiding users through the discussion rules and etiquette. I personally want to point out some interesting suggestions about making the threads and banners visually separate, but still on the same page. There was no clear idea, how to achieve such a thing, but some strong visual eye-leading to what the user looks for would work! There were suggestions to wrap banners, skip banners by a button, but per our community discussion better would be to just leave them as is and isolate them visually. Also there must be a place for talk page metadata (archivation, preferences, etc.), this could be a part of them.

At his point the Phase 2 community discussion created another point, let's call it point 7:

  1. Several people mentioned there should be some system of notes. People could add notes to individual lines of articles. These notes could work like threads, but lighter. They perhaps could be in a separate namespace, or automatically posted to talk page as a thread. This would require to link the position in the precise article revision to the thread/note somehow, either on thread/note side (coordinates), or on the article side (anchor). Similar approach works on OSM and also in many programming tools (GitHub). There is no need to move this comments, have the comments history, just they should be archiveable, closeable and removable. This topic has also been discussed with Growth team separately already and it seems Czech community likes the idea.

To sum this all up: The community is ok with any changes, even the major ones, as far as it makes the talk experience on wikis better, more clear, clean, searchable. There could be used so many already existing features and repurposed on discussion pages. But the developers should always think about long-term editors and newcomers, old (technically-unexperienced) and young (chatting all over the internet) users. Extra care should be done to make the product stable and also not completely changed as many long-term editors and novices could become sick of never-ending major changes in talk pages. For the Czech community, Dvorapa (talk) 02:10, 16 June 2019 (UTC)

English Wikipedia[edit]

Apologies for submitting this late.

In lieu of a full summary, which would probably be difficult to compile by an individual without omitting a substantial amount of content or committing more than a full day solely to working on it, I have constructed a small statistical analysis of the responses to question 1 (which asks if users agree to the proposed direction) by separating the respondents by how they answered and their edit count and account age. 75 (62.0%) of the 121 participants commented in this section, and many did not participate in the other sections.

I have sorted the comments into three groups based on their level of support; for the graphs and tables I have merged two of them in order to have a larger sample size. Note that the "Other" category (i.e. the two merged groups) comprises all users who I determined did not support the proposed direction with no significant caveats, including users who indicated cautious support depending on technical or other caveats, users who indicated opposition because the proposed direction's changes would be unnecessary, users who indicated opposition because the proposed direction did not go far enough, and users who did not seem to indicate support or opposition at all.

In the Data section, I have also separated the comments by whether or not they add anything substantive to the discussion. To simplify this, I've assumed that everything other than a support with no caveats should be reviewed by the team, and have also noted seven other users who added substantive suggestions in their comments. I would personally suggest that the staff review all of the individual comments in the other sections; it helps that all of the team members can speak English.

While my analysis is somewhat limited, it should be possible for the team to conduct further analysis if desired due to all the relevant data being publicly accessible. Jc86035 (talk) 15:51, 1 July 2019 (UTC)

Edit count[edit]

The edit count is the one provided by the English Wikipedia's MediaWiki API and may be inaccurate (see phab:T21311).

User type Edits
Mean Median Total
Support (no caveats) 19120.90 3798 1109012
Other 11428.53 3517 194285

Account age[edit]

The statistic used is the English Wikipedia account age, if available. (AnimeJanai's account does not have an entry in the user creation log, so I have used the date of their first edit, which is 2006-12-06 22:23:23.) All times are UTC. The analysis in the table is based on Unix time and as such does not account for leap seconds.

User type Account creation time
Mean Median
Support (no caveats) 2012-12-11 00:26:09 2013-03-28 20:23:33
Other 2007-09-16 07:37:27 2005-07-23 11:43:24



  • While this is not included in the data, a lot of users would want to opt-out of the changes entirely or as much as possible. Disruption to workflows seems to be the main factor for these users.
  • A large number (15) of the users signed up in 2018; I think the simplest explanation would be that editor retention decreases as account age increases. (Seven users registered in the first half of 2018, whereas none of the users registered in the second half of 2017.)
  • The two groups of "support" and "other" differ primarily in average account age, with the means separated by more than five years and the medians separated by nearly eight years.
  • Overall, users who signed up before 2007 were much more likely to be skeptical of the proposed direction. (The English Wikipedia experienced substantial growth in terms of content in the late 2000s, but its rate of growth peaked in the mid-2000s. The number of monthly active contributors more than doubled annually from 2001 to 2006, and peaked in early 2007.)
  • Users who supported the direction without caveats had a higher mean edit count and a higher median edit count, although not by much. This may have been affected by how I chose to categorize certain users into the "Other" group.
    • Of the three users with under 100 edits in the "Other" group (Bachn, Charis and 0w0 catt0s), I categorized Bachn as such primarily because they indicated that they agreed with Risker (who voiced some concerns); Charis supported the direction but was concerned that the proposed improvements to indentation would be inadequate; and 0w0 catt0s neither supported nor opposed the direction but provided some suggestions. The users respectively signed up in 2018, 2015 and 2019, constituting the only users in the "Other" group who created their accounts after 2009. If the three users are removed from the "Other" group, the mean edit count becomes 13863.64, the median edit count becomes 7693.5, the mean sign-up date becomes 2005-08-03 03:15:00, and the median sign-up date becomes 2005-06-21 19:02:59.
    • Excluding those three users, the newest account in the "Other" group is Gryllida (2009-08-03 05:16:03). All other users in that group signed up between 2003 and 2007.
  • Users with more edits were generally more likely not to support without caveats, although none of the three editors with more than 100,000 edits are in the "Other" group.

English Wikisource[edit]

Sorry, thought I did this already.

Four users contributed.

  1. Clearer design of talk pages seems reasonable. However, it needs to result in valid markup, and needs to be available on discussion pages outside of Talk space (e.g. s:WS:S).
  2. Separate discussions can be handled like on Commons and Wikidata, by having them on separate pages, and transcluding onto primary discussion page. This procedure would need to be streamlined so as to be easy for new users.
  3. Always good to make things easier for new editors. Adding more discussions (such as per section) will add to current problem of too many talk locations, and would not apply to Wikisource anyway. New editors tend to edit at meetups and will discuss outside the WS platform.
  4. It is necessary to streamline tools and talk templates so as not to break large talk pages.
  5. In some places the history of a single discussion is most important, but admins need to be able to see full page history in order to deal with e.g. vandals who edit full page. Diffs also used for tracking conversation history: who said what when.
  6. Aside from central discussion pages, talk pages are usually used to store metadata and not used for discussion. One user suggests having separate tabs for metadata and for discussion. One user suggests only having metadata on those pages, and redirecting discussion to central location.

Beleg Tâl (talk) 15:12, 15 July 2019 (UTC)

Federal MediaWiki Community of Practice[edit]

The Enterprise MediaWiki Community of Practice (CoP) works to help reach the potential of Enterprise MediaWiki sites through open dialog and sharing good practices among U.S. Federal agencies. Based on our discussion,

  • People are often intimidated by creating a talk page. Could that barrier somehow be removed so potential commenter are presented with a black page to create?
  • It would be wonderful to have a dashboard, maybe similar to W:Special:NewPagesFeed, where all comments on talks pages could be seen and maybe even provide a way to replay.
  • Could something similar to the old Article Feedback tool v5 be added at the bottom of pages to make it easier to create a new discussion topic? People often look the bottom of articles for comments.

Thank you for the opportunity to provide comments. --PhotographerTom (talk) 21:36, 21 June 2019 (UTC)

French Wiktionary[edit]

Only two particpants gave their opinion. You can read the discussion here (in French).

  1. What do you think of the proposed product direction?
    The proposal is considered pragmatic. Users do not want to change their habits massively so it is necessary to do it gradually. A clear design is helpful to identify easily a talk page from a main page.
  2. Marking separate discussions
    This is interesting. The advantage is this is not a big change for users who already know the wikicode. The new evolutions will have to be fully supported by the visual editor as they are implemented in order not to exclude users who do not know wikicode.
  3. Helping newcomers find the talk pages
    The Wiktionary users worry about the way this new feature will be implemented. On the French Wiktionary, it could be useful to have a talk page by section (see nata for example; the idea is to have on talk page by language (Français, Catalan, Espagnol, ...)). However, it may be really messy to develop something user-friendly and not messy.
  4. Where to show discussion tools
    The French Wiktionary users who gave their opinion agree to move all the discussion on the Talk namespace.
  5. History tradeoffs
    The French Wiktionary users see a lot of advantages to split the history by section (instead of the full page) for readibility reason. It will also make easier to find who made a given contribution. It is proposed to be inspired by the blame function of the version control softwares.
  6. Metadata location
    There is no such page on the French Wiktionary, so we have no opinion on this point.

Pamputt (talk) 17:08, 19 June 2019 (UTC)

German community[edit]

79 contributors made comments on de:Wikipedia:Projektdiskussion/Globale Konsultation zum Thema Kommunikation 2019/Phase2.

General acceptance, & structuring talk pages[edit]

Most people would welcome a better usability of talk pages. Signatures for instance could be added automatically, without relying on other users, or bots. Appropriately identing the paragraphs with colons is unnerving. There should be an 'answer' button below each post, other people's posts should be protected, and WYSIWYG editing on talk pages would be a good thing. Some people added their own experiences with ennumerating syntax, changing subject lines, and so on. Especially strong endorsement came from people who are active in introductory courses and OTRS. Most participiants opted for new and better tools, some even pressing for a complete software turnover, to get rid of dead wood. On the other hand en:Wikipedia:Flow is still in bad memory, having no remaining proponents at all (63 comments.)

Several participiants emphasized the overall success of MediaWiki and disclaim 'difficult talk pages' as our worst problem, or even a problem at all.

An even more categorial position denies the value of contributions from people who do not have system skills. According to it en:WP:AFT showed that easements for everyone could result in eating volunteer time, adding little value, and leaving dissapointed users who are not getting timely responses. "Wikipedia is not Facebook" summarizes this position (7 comments).

Moderate critics fear a coexistence of old and new UI parts would increase the overall complexity. Old and new users might get their wires crossed because they get more different experiences. Fluent users would easily jump from one editor to another, which is no option for newbies. Help pages written by old users would get outdated, or they would't adress the new users' issues.

3 users underlined that easy-accessible talk pages do attract external readers, and their content can be more interesting than the condensed article. Discussions are a pivotal part of our project. Software must in no way thwart free discussions. Even mandatory structuring discussions into 'threads' could be restrictive and contraproductive. en:Wikipedia:LiquidThreads were firmly objected to in this context.

One user suggested to implement a test phase of 6-12 months.

Positioning of links & discussions[edit]

The GUI suggestions were supported by most comments, with some emphasis on optical hints which indicate the actual page's dedication (41 comments). One user suggested to combine the multitude of article talk pages into fewer, topic-related pages.

Most users opposed narrowing down the talking only to pages in 'talk' space. This would interfere with longstanding practices in our community. Software should be enabled to identify any page as 'talk page', in all namespaces, if it has been tagged accordingly (10 comments).

Page history[edit]

Providing section-specific histories did not get much support. None of the 15 comments were in favor of that. Text search in the history would be nice-to-have, though (15 comments).

Templates on talk pages[edit]

This is overwhelmingly seen as a community issue. We try to limit such hints and rules to the necessities, but we claim them as our responsibility (15 comments). -- Summary by --MBq (talk) 10:12, 16 June 2019 (UTC)


Nine users, including one unregistered user, participated. As with the previous discussion, the small number of participants makes it difficult to really summarize some of the sections.

Again, apologies for submitting this late. Jc86035 (talk) 17:31, 4 July 2019 (UTC)

Main questions[edit]

  • What do you think of the proposed product direction?
    • Four out of seven of the users, if we include myself, were supportive, but the other three users had doubts. One user (MisterSynergy) would prefer a Flow-like solution that goes further than the existing software. One user ( seems to be saying that making the software easier to use would be the wrong approach altogether, due to there being too many other factors acting as deterrents to new users. One user (Ash Crow) does not support nor oppose the direction; instead they note any indentation hampers readability on mobile due to the smaller screen width (i.e. text gets squeezed), and that the new software should be able to handle template-based localization (Flow doesn't).
  • Marking separate discussions
    • Only two users responded. ArthurPSmith says "I suppose this is fine", and wonders how subheadings would be handled. MisterSynergy says that the proposed changes sound "fragile as hell" if users would be able to break discussions.
  • Helping newcomers find the talk pages
    • Of the three users who responded, one (Dreamwoven) is skeptical since making discussion pages more visible might "[encourage] unfocused posts, blogging [and] soapboxing". ArthurPSmith suggests linking "in the nav bar on the left-hand side of the page". MisterSynergy suggests that testing, involving "different link positions and link texts" and skins ("particularly the modern Timeless skin") could be used to find improvements.
  • Where to show discussion tools
    • Both users who responded are against moving all fora to Talk namespaces. ArthurPSmith notes that many important discussion pages, such as property proposals, are in non-Talk namespaces. Arthur also suggests that talk pages could be disabled for non-Talk pages which function as discussion fora. MisterSynergy suggests a toggle to enable or disable "discussion mode", and says that "it would be desirable if the talk pages had a clearly different appearance from content pages".
  • History tradeoffs
    • Two users responded. ArthurPSmith says that he would prefer a solution with thread history and an overview for whole pages ("when discussions were added to [the page] or removed from it and by who[,] for instance"). MisterSynergy says that his workflow does not involve looking at "dated contributions" since signatures are sufficient; however, he says he would "weakly prefer discussion histories over page histories".
  • Metadata location
    • Only two users responded, including myself. I noted that it would probably depend on whether the level of disruption would be acceptable. MisterSynergy says that he would want some sort of resolution for the issue, but isn't sure "where [metadata] should go".

Other questions[edit]

  • Straw poll: prioritization
    • Four users responded here. Excluding myself, all three other users answered that "automatic thread archival and link handling" would be their first choice out of five for development prioritization (I answered with "new discussion interface with inline replying" as my first choice). I also asked the question on the English Wikipedia, where about ten other users responded; it could be useful to analyze the combined data.