User talk:Jc86035

Would you take a look at User:PPelberg (WMF)/sandbox and let me know if it makes sense? If it's confusing to someone like you, then I need to re-write it entirely.

I'm not sure if I would be the right person to ask. Am I really representative of the target audience? If the text contains jargon that would only be understood by a subset of editors, I might not notice, but someone else might.

My open questions that weren't answered by the page:

• Who is the target audience?
• Who gets to modify the content of the RFC? Would non-staff members only be able to make changes to some sections, or would we be unable to make any changes at all?
• How concrete are the proposals? Primarily, for proposals B and C, is it likely that a different set of characters would eventually be used during implementation?
• If I don't like <dl> or <dd> tags (or some other part of the output HTML, as opposed to the wikitext) being used on talk pages, would that affect the RFC at all? In other words, is the scope of the RFC limited solely to the proposed changes to the grammar of wikitext?

The target audience is people with qualities that you combine: experienced editors who use wikitext and people who know something about wiki-related tech stuff (any level of technical skill). The one important quality that you don't have is using a non-English keyboard (because if typing certain characters is really difficult in some languages, they really need to know that).

"The RFC" happens in multiple places, several of which (e.g., e-mail) don't have any method for changing what other people wrote. Alternative proposals are welcome, and should be proposed in discussion (e.g., a reply e-mail message, a section on the talk page). There could be an option "E", or "C.2", etc.

The syntax for A and B is set in stone, because A and B connect to other work (e.g., T114432 for A). Deciding that you wanted mostly A but to use %% instead of <<< would amount to a (partly) new proposal. Proposal C is not set in stone; it's just a copy of a conventional approach used in e-mail, with no history in MediaWiki. Some e-mail systems turn that into an indentation (like a forwarded message). Changing the characters typed wouldn't change the nature of that proposal.

If you don't like HTML tags, then you should vote against option D. This won't affect only talk pages; any wikitext that works on talk pages will work in articles, and vice versa. I'm not certain that I understand the last question. The scope of the RFC is about expanding wikitext (unless you vote for option D, in which case they'll use the existing methods, which means scattering raw HTML across talk pages).

Essentially, the content of the last point was just about the concern that has been raised in previous discussions about how <dl> and <dd> have specific semantic meanings that don't really fit on talk pages. As an example, if option A were to be implemented without any additional changes, the project might well conclude without the replacement of the <dl> and <dd> tags, and either a parser change to interpret definition lists without any <dt> tags differently (T6521) or new syntax (the addition of option C) would be necessary to avoid that outcome. The presentation of the options sort of implies that at most one of the options will be chosen even though they aren't mutually exclusive.

I agree with you that <dl> and <dd> have specific semantic meanings that don't really fit on talk pages, but <dl> and <dd> are actually appearing in the HTML on talk pages, and there is no current plan to change that.

In this RFC, options A, B, and C would improve the current HTML (in which the <dl> is broken if you put a thumbnailed image in the middle of an "indented" thread) via the addition of a new wikitext "code"; option D would improve the current HTML via the addition of <dl> tags in the middle of the wikitext. All options would produce (approximately) the same HTML for the reader. The difference for editors is primarily in what you'd see in the diff.

Could you please look at Talk pages project/replying/prototype testing#Reply tool version 2.0, try it out, and let me know what happens? I want to make sure that the directions work before sharing this link more widely, and of course I want to know what you think about the tool anyway.

Hey, I don't know if you keep track of replies in Phabricator and it has been a couple of weeks since you filed https://phabricator.wikimedia.org/T244672 but I just wanted to let you know that I've replied and that we appreciated the time going into filing this report. We do indeed see it also as a technical problem, and are investigating the technical feasibility of the suggestions.

We appreciate you trying the prototype and sharing this clear and thorough feedback.

So you're aware: we expect to engage with these comments the week of 6-January-2020...many members of the team will be on holiday until then.

Yikes – good catch. Thank you!

Hello Jc86035. Regarding [https://www.mediawiki.org/w/index.php?title=Talk_pages_consultation_2019/Phase_1_report&oldid=prev&diff=3234002 German Wikipedia], you underestimate the senstivities of Austrian and Swiss Wikipedians. This is a discussion that is going on for more than a decade. Most Austrians and Swiss feel hurt when de.wikipedia is seen as the "German" Wikipedia. So everytime de.wikipedia is mentioned it is refered to as "German language Wikipedia" instead of "German Wikipedia".

I understand why you would do this in German, but is this normal in English-language usage? I'm not familiar with this issue [in my defense, language is arbitrary, I'm fairly familiar with how the words are used in English, grammatical rules don't automatically carry over from German to English, and the word "German" can obviously refer to both the language and the country], but presumably there's a fairly good reason that w:en:German Wikipedia has had its current title since the article's creation (and has been move-protected since 2009).

If dewiki has to be the "German-language Wikipedia" then I would be fine with the same being done for all of the other wikis, but probably not just dewiki.

One on hand you write that you are not familiar with this issue, on the other hand you revert me. It is not so important for me though.

In re this, I'm not sure that not being able to contact new users would have made much difference at Commons. The un-reachability of newbies there is a very frequent complaint. I don't know whether the new folks at Wikidata have the same pattern. Thanks for making a note about the situation.

Hello

You have volunteered to be a coordinator for the Talk pages consultation 2019. Thank you!

We want to share with you some important information, so as some advice. All of this is based on feedback, observations and some decisions taken around phase 1 of the consultation.

Can you ask for details?

On the already started consultations, we have noticed that some people explain what they wish to have, and they express what they like or dislike about talk pages. However, they don't explain the reasons why.

Explaining why is very important: it allows us to find the common needs between users. Can you please review the feedback already received, and ask for details and "why"?

Reaching at other projects

Most of the consultation pages are hosted on Wikipedia, on several languages. We also need to get the feedback from people who contribute to other projects. Don't forget to invite them to participate (or setup their own consultation page). The more feedback we have, the better.

Reaching at newcomers

Most feedback received so far has come from experienced users. It is unfortunately not representative of all the users who use talk pages. Please consider to send an invite to some active newcomers. Again, the more feedback we have, the better.

To find some newcomers to contact, you can replace the RecentChanges link on your wiki with the following set of filters: Special:RecentChanges?userExpLevel=learner&hidebots=1&translations=filter&hidecategorization=1&hideWikibase=1&namespace=1%3B3%3B5&limit=500&days=30&urlversion=2. It will show the list of users who have made less than 500 edits, and some edits on discussion pages. You can also invite people who left messages on your local Help desk.

Due date is now known!

Community summaries are due by April 6, 2019. We advise communities, especially the ones that would have had collected a lot of replies, to end the conversation by March 31. That way, volunteers will have enough time to wrap up the discussions.

How to close the conversations?

We have seen that some of the coordinators have started the conversations using the usual places to have conversations on their wikis. It is an easy way to reach people. However, since the consultation is based on a different consultation process than the usual ones, those rules regarding how to close conversations may not need to be applied. It is up to you to decide!

And again, thank you for your help!

Trizek (WMF) 17:03, 1 March 2019 (UTC)

@MattLongCT, DannyS712, Cygnis insignis: Since you expressed interest in closing the discussion, what do you think would be the best way to notify users? I don't really know if I would want to do all of this myself. Carrying out the request could fall afoul of the canvassing guideline, although I think it's probably appropriate in this case because the WMF specifically wants feedback from more new users.

The Special:RecentChanges setting results in 1,592 different users (at the maximum setting of 5,000 entries, which goes back to 01:54 on 27 February). This is probably far more than necessary, and I don't know if it would be acceptable to notify all of them.

I can help, but only on certain days and at certain times. Please let me know how I can help!

I am not a mass message sender. I therefore do not know if I would even be able to message all those people for you. I could apply to get it, though. ~~~~

Welp, I signed the message like a chump lol

It could be possible to do it manually using JWB – i.e. by holding down the keys for the "save page" keyboard shortcut. This would probably be faster than requesting mass message rights.

My main concern is whether it would be acceptable for me to notify so many users, particularly such a skewed group (edited an article talk page in the last four days + autoconfirmed but not extended-confirmed). This also has the negative site-effect of filtering out users with more than 500 edits, and it might also be appropriate to notify a similar group of extended confirmed users who edited article talk pages in the same time period, as well as users who commented within certain community processes.

I'm also concerned about whether those editors will find the discussion daunting, given its size. It might be appropriate to ask them to comment on the talk page of the discussion if they don't know where to put their comments.

@Trizek (WMF): Around how many users should be notified? There are probably several thousand English Wikipedia contributors who could be sent this notice, using your criteria.

Don't use AWB/JWB for these ventures. I used AWB in informing about 76 of those who participated at and it was a boring experience. Mass-Message-Right(s) are easily disbursed with, provided you have some solid rationale and the tool's incredibly easy and fast to use.

FWIW, I was thinking of writing a query that generates all users having 20-500 edits who have at-least made 2/3 edits to the t/p in the past 4 months and are currently unblocked. And, then mass-message......

I agree, a query would probably be better than abusing Special:RecentChanges. I think the threshold could be increased to 1,000 edits (or even 10,000), since most of the editors who have commented have several tens of thousands of edits. Maybe the query could also search for Teahouse and AFD participants, or something like that?

This is an important question, yeah..

I already have mass message rights, so I can help send the message.

@Jc86035

Around how many users should be notified? There are probably several thousand English Wikipedia contributors who could be sent this notice, using your criteria.

Good question. From my experience, the reply ratio for experienced users on a wiki like yours is between 1/20 to 1/50. The key element here is to have a good call to action. Insisting on how their experience as newcomers is important. It will give them more confidence on participating.

Ping me if you need any help.

I don't truly know why the devs created multiple parsers. However, I assume that their reasons include the old parser being due for a re-write anyway, plus the opportunity to debug a "replacement"[1] without screwing up all the wiki pages in the meantime. I could be wrong.

[1] NB that I am not saying that Parsoid itself (rather than, for example, some other parser that is partially derived from Parsoid and partially derived from the old parser) will actually replace the old parser. I don't know exactly how they plan to handle that detail.

Oh, okay. Thanks