Pre-LQT/Flow comments can be found at User talk:Qgil-WMF/Archive 1

Re: User talk:Mitevam#Vendors_table_in_own_page

edit
Mitevam (talk) 17:07, 11 January 2013 (UTC)Reply

Amsterdam Hackathon 2013

edit

Please don't move pages to useless names. Thank you, Multichill (talk) 20:57, 16 January 2013 (UTC)Reply

Thanks for helping us getting out of the box

edit

Hi, I'm Clement Dietschy (or bedhed), founder of Seizam. Thanks for the note in the news about our Video (from the 18th). It's always great to feel we're doing good. Do not hesitate to contact me if you wish more information. Also, we'd be delighted to invite you (or friends) on Seizam for free. Cheers!


-- Clément Dietschy 75020 Paris tél. +33 6 87 75 99 27 -- Seizam Sàrl. 24, rue de Bâle 68300 Saint-Louis (France) tél. +33 970 448 200 www.seizam.com

ClementD (talk) 14:46, 23 January 2013 (UTC)Reply
22:09, 21 February 2013 (UTC)

Hi, would you like to tell me how can I leave a message without being reverted?

edit

Should I completely finish my proposal now and then post that to the page Summer of Code 2013? KeepOpera (talk) 16:25, 13 March 2013 (UTC)Reply

Sorry if I removed anything from you. What I reverted was in fact some spam that was added right before your post by another user. Feel free adding your text again and sorry again for the inconvenience. Qgil (talk) 16:40, 13 March 2013 (UTC)Reply

Outreach Program for Women

edit

Hi Quim.

Regarding this edit, you should never use rollback on a non-vandalistic edit. It's seen as a "slap across the face" on nearly any MediaWiki or Wikimedia wiki. From m:rollback:

Rolling back a good-faith edit, without explanation, may be misinterpreted as "I think your edit was no better than vandalism and reverting it doesn't need an explanation". Some editors are sensitive to such perceived slights; if you use the rollback feature other than for vandalism (for example, because undo is impractical due to the large page size), it is courteous to leave an explanation on the article's talk page or on the talk page of the user, whose edit(s) you have reverted.

Your actions here were particularly egregious as you not only used rollback on a non-vandalistic edit, you also broke the Wikimedia Engineering page and didn't bother leaving a talk page note on my talk page or Talk:Outreach Program for Women.

BRD is an old wiki principle and I'd be happy to discuss my edits, however your behavior here has been simply unacceptable and I can flatly guarantee that if you continue to use rollback in this manner, you'll very quickly no longer be able to use rollback at all.

I've partially re-reverted your edit in this edit to fix Wikimedia Engineering. If there's some issue with the infobox (it's now being hidden with CSS), please explain the issue somewhere so that it can be discussed. Blindly reverting (particularly using rollback) is just about the fastest way to piss people off in a collaborative wiki environment. MZMcBride (talk) 17:21, 16 March 2013 (UTC)Reply

(after a long IRC chat) Yes to everything and now everything is clear. Thank you for your effort and your patience with my excessively bold edits. Qgil (talk) 18:18, 16 March 2013 (UTC)Reply

Enabling LQT

edit

Hey, could you please in the future refrain from enabling LQT on pages with existing discussions? Even in general the net benefits of LQT are questionable, but when a page is converted that makes the content a lot harder to follow and adds needless confusion.

I do bring this up in part precisely because the net benefits are so questionable, however, as I would argue that this initial confusion is not a necessary cost for something overally useful in the long run because LQT is if anything damaging in the long run. Instead of removing barriers for new users, it presents new barriers for those coming from other projects, as they are not used to it, it is massively unintuitive, and the differences cross-project are staggering enough as it is. It is hard enough for many users to step out of the comfort zones of their home projects without strange technical issues such as LQT presents.

And they are technical issues - having a reply button is nice, but the complete lack of integrated notifications when someone uses that reply button makes it a lot harder to follow updates to discussions, especially if they are happening at the same time as and relevant to stuff happening on one's watchlist. None of it shows up on the watchlist at all, as LQT does not have a meaningful history, and as a result apparently the only way to go back and find a discussion later (after already having marked it as read) is to go to the page and find it on the page.

So yeah, please don't do that. -— Isarra 18:05, 19 March 2013 (UTC)Reply

"they are not used to it, it is massively unintuitive" is a very good description of a MediaWiki Talk page behavior for most humans out there. I'm pushing LQT in existing pages only when they have a clear outreach focus, beyond the Wikimedia usual suspects. That is the case of Product development, directly linked from How to contribute.
Sending newbies to raw Talk pages feels almost like suicide to me. We are lucky enough to have LQT enabled in mediawiki.org and maybe one day Flow will solve everything. In the meantime I believe that newcomers will enjoy a lot better an underfeatured web based forum than a MediaWiki Talk page.
But you do have a point, and from now on I will ask in advance when there is an existing Talk page that I want to replace with LQT. The decision will come from the discussion that page. Qgil (talk) 18:24, 19 March 2013 (UTC)Reply
If LQT fully worked I'd agree entirely, but some aspects are pretty bad, especially the watchlist stuff. Add that the folks coming into this probably will be familiar with mediawiki, what with people working with open source usually because they use it, they probably don't need this anyway in most cases.
Anyhow, thanks. -— Isarra 21:34, 19 March 2013 (UTC)Reply
You posted this on March 19th, but then enabled LQT on talk:MediaWiki-Vagrant without asking. The wiki principle of being bold is predicated on the ability to go back and do things differently, but with no way to opt-out without obliterating content, LQT is not wiki. I think you ought to stick to the guidelines you articulated above. Ori.livneh (talk) 04:23, 29 September 2013 (UTC)Reply
Hi Ori.livneh! Well, the discussion was about existing Talk pages, not about new Talk pages, as it was the case with MediaWiki-Vagrant. I can't remember when was the last time I activated LQT in a page but I hereby commit to not do it anymore unless there is an explicit request. I'm waiting for Flow patiently. Qgil (talk) 05:59, 29 September 2013 (UTC)Reply
Thanks :) Ori.livneh (talk) 06:49, 29 September 2013 (UTC)Reply
edit

You know, traditionally cc-by-nc-nd files are not allowed on Wikimedia projects - is the gsoc logo you just uploaded allowed? Maybe it would be considered fair use? Bawolff (talk) 17:31, 22 March 2013 (UTC)Reply

I uploaded it only in MediaWiki, not Commons, with the sole purpose of illustrating the GSOC page. If this is not good enough I can remove it. Qgil (talk) 18:05, 22 March 2013 (UTC)Reply
The license Google gave to it allowed the way it was used: attributed, non derived and in a non-commercial project. However our own policy at mediawiki.org is more restrictive. I think it made a service in a page like GSOC'13 but being an admin I'm in no position to contradict a policy.  :) It's deleted now. Qgil (talk) 06:06, 24 March 2013 (UTC)Reply

Responded to Message

edit

Hey, I responded to your message on my talk page. Also, how is your talk page LQT? Parent5446 (talk) 06:31, 25 March 2013 (UTC)Reply

I saw it, thanks. LQT, just click Edit and you will see {{#UseLiquidThreads:1}}.  :) Qgil (talk) 16:40, 25 March 2013 (UTC)Reply
Ah, I see. Thanks! Parent5446 (talk) 18:15, 25 March 2013 (UTC)Reply

GSOC 2013

edit

Hi Quim, I want to apply for GSOC 2013. I have drafted a proposal on my user page. The project is not from the listed featured project ideas list, its my own idea. I would like to know its feasibility and whether am I late to post this? I wanted to come up with a full descriptive proposal. Gaurav Chawla (talk) 19:16, 5 April 2013 (UTC)Reply

Hello Gaurav! You are not late, you are just in time. It is good to see all the good work you have done so far.
This is an interesting idea but I'm unable to assess its feasibility, neither its potential reception by the community, or whether similar projects exist or have been attempted in the past. It would bring a very visible new feature, a new user interaction and a new editing process. This might be too much to digest for e.g. the Wikipedia community but maybe your idea is seen interesting as a MediaWiki prototype, and who knows what would come out of this.
The steps I recommend you are:
  1. File an enhancement request in Bugzilla under MediaWiki Extensions - Entension requests proposing your project, introducing it briefly and linking to the URL with the full description. You can add me on CC and I will help you gathering a first wave of feedback. If this is not enough then you might want to post the idea to wikitech-l mailing list, linking to the URL of the project and requesting more feedback in your report in Bugzilla. Or you might want to do this directly, after creating your report.
I'm sure that a couple of days later you will ave enough feedback to decide what to do next. Good luck! And thank you for your interest contributing to Wikimedia. Qgil (talk) 01:16, 6 April 2013 (UTC)Reply
I have filed the request at bugzilla:46970. Gaurav Chawla (talk) 20:12, 6 April 2013 (UTC)Reply

Bosnian

edit

Hi Qgil! Can you please add Bosnian to this list so that it shows on the list of languages on the start page? Template:Languages. Thanks in advance! -- Edinwiki (talk) 21:10, 7 April 2013 (UTC)Reply

There is already a link to bosanski in the main page. Thank you for your work translating! Qgil (talk) 03:11, 8 April 2013 (UTC)Reply
Someone else had added the language before you had to chance. Thanks anyway. Edinwiki (talk) 18:47, 17 April 2013 (UTC)Reply

Summer of Code proposal feedback

edit

Hi Qgil! I've been working on my Summer of Code/OPW proposal and was hoping to get some feedback on it before I got too far along. It's not on the list of recommended project ideas, so I wanted to make sure you thought it was feasible and that it had some chance of receiving broader support. Thanks! (talk) 12:49, 11 April 2013 (UTC)Reply

Interesting idea, and very good project proposal structure overall. You have clearly invested a lot of thought and time already. Congratulations?
Have you found a mentor? In any case, the next steps recommended are:
  • Creating a new enhancement request in Bugzilla, unless there is already an open report about this.
  • Sending an email to wikitech-l pointing to the wiki page of your proposal and the bug report.
Good luck! And see you there. Qgil (talk) 14:16, 11 April 2013 (UTC)Reply
I have not found a mentor yet, no. I sent an email yesterday to User:Raylton P. Sousa, who maintains the BookManager extension and was on the mentors list for GSoC 2012, but I've not heard back as of yet. Do you have any suggestions for people who might have relevant knowledge and would be willing to mentor?
As for Bugzilla, there are quite a few bugs that are somewhat related. The issue of having a way to represent books is namely mentioned in bug 15071. There are also a number of bugs specifically related to the BookManager extension here. Do you think I need to create a new request, or are these close enough?
I will send an email to wikitech-l shortly.
Thank you! GorillaWarfare (talk) 14:54, 11 April 2013 (UTC)Reply
Bug 15071 is blocking several others and it's followed already by 12 people, including some maintainers that have commented. So yes, it's a good destination to announce your project proposal.
Raylton was indeed interested in mentoring. Being a maintainer of the BookManager extension and a pt.wikibooks.org admin he seems to be the ideal mentor for your project, yes. But you don't need to wait for his answer to announce your project idea at Bugzilla and wikitech-l.
But before I would still try to polish your project summary a bit. Are you able to summarize in one sentence the solution your project aims to deliver? If you can, use it as opening of the summary. It's amazing how impatient readers are nowadays...  :) Qgil (talk) 15:22, 11 April 2013 (UTC)Reply
Alright, I will announce the project there and on wikitech-l after I put a little more work into the proposal! Thanks for the feedback. GorillaWarfare (talk) 15:33, 11 April 2013 (UTC)Reply

GSoC participation

edit

Hi Qgil, I'm interested in participating in the GSoC 2013. I'm a graduate student (IT) in my last semester of college and a prolific contributor to Wikipedia. I've some queries. If and when the time comes, I am wondering whether it is necessary to reveal my private information publicly? And, how can I apply to work on any proposed project? Thanks and regards. Bill william compton (talk) 03:09, 26 April 2013 (UTC)Reply

Hi Bill, thank you for your interest in working on a Wikimedia project. Summer_of_Code_2013#Where_to_start and Mentorship_programs/Application_template should answer your questions. Summary: everything public, please. And the sooner you start sharing your drafts the better. Qgil (talk) 03:18, 26 April 2013 (UTC)Reply
Wow, you are really quick on replies! Thanks. By everything you mean real name and location as well? Don't you think it's against the privacy policy? Due to some reasons, I cannot reveal my real name and location. I wonder how regular Wikipedia contributors participate in such events if they have to give up their personal info in the process. Bill william compton (talk) 04:04, 26 April 2013 (UTC)Reply
Ok, it is up to you to disclose or not your personal data publicly. What we really care is about public proposals and public technical discussion in our regular community channels. Sorry for the misunderstanding and we hope this is clear now. Qgil (talk) 04:35, 26 April 2013 (UTC)Reply
Yes it is :) Merci beaucoup! Bill william compton (talk) 04:48, 26 April 2013 (UTC)Reply

French-speaking MW community

edit

Hi, I began a discussion in the French-speaking community about some exchange space (mailing-list, forum, whatever) about discussions in French related to MediaWiki. There is some demand from MW sysadmins who don’t know well MW and are not fluent in English; I don’t know where this discussion could lead, so we’ll see.

(I don’t know if I should speak of that to you or Sumanah or Guillaume, so I let you transmit if needed) ~ Seb35 12:19, 20 May 2013 (UTC)Reply

Bonjour! I'm a good contact for this and fwiw I can even read French (but not write it, all I get is my Catalan disguised).  ;)
Just in case this is useful: Mailing lists/Regional & Groups. Qgil (talk) 16:03, 20 May 2013 (UTC)Reply
(Bumped into the thread by chance.) Seb, that's interesting. Past mailing lists (sv only?) don't seem successful. For Italian I know #mediawiki-it is dead (as well as #botolatori) so it wouldn't make sense to create a mailing list for us; the problem is that we don't even know who Italian MediaWiki users are... but if the French find a solution then there may be some emulation. ;) Nemo 05:50, 28 May 2013 (UTC)Reply
Hi, the list is created on the Wikimedia CH server [1]. I announced it on lists wikifr-l@, WMFR technical list (tech at lists.wikimedia.fr) and wikis-territoriaux at lists.infini.fr, I completed the page given by Nemo, and I announce it on wikitech-l@.
Regarding to a regional MW groups I discussed with some people interested by MW in France, and the first action we thought was some discussion space (hence this discussion list); perhaps there will be some other action like a meeting of French MW-interested people, and perhaps there will be a more formal group, but nothing is fixed for now.
@Nemo: in France, there are a lot of local/city wikis [2] [3], and their community managers frequently have technical questions (e.g. regarding the spam or config); I think some enterprise wiki managers could be interested also by such a list. We will see if the list survives. ~ Seb35 10:58, 23 June 2013 (UTC)Reply

My general suggestions

edit

Hi Qgil, some time ago you said you were curious about a bunch of general suggestions I had for the software. I haven't reported them through Bugzilla yet, but today I copied them to my userpage. Many are probably already reported, many others are probably bad ideas, but a few should have value. Just letting you know, cheers! LFS (talk) 11:46, 17 June 2013 (UTC)Reply

Template:New opportunities/Content

edit

Heiya Qgil,

I am not absolutely sure if you are the right one to ask. However, it would be nice if you could add the following announcement to the new opportunities template (linked above):

October 28-30, 2013 - Berlin, Germany

Thank you and cheers [[kgh]] (talk) 17:16, 18 June 2013 (UTC)Reply

This did the trick. (Pause) Yeah, I know.  :) Qgil (talk) 20:31, 18 June 2013 (UTC)Reply
Admittedly I am puzzled by this trick. :) I will have to have a close look into this. Anyway, thank you for your help! Cheers [[kgh]] (talk) 21:19, 18 June 2013 (UTC)Reply
It's all User:Guillom's fault. :D
By the way, you can send an email to wikitech-announce@lists.wikimedia.org and we will approve it for distribution. Qgil (talk) 21:27, 18 June 2013 (UTC)Reply
Aha, now I know. :) Thank you for suggesting the wikitech-announce. I guess we should give it a go. :) [[kgh]] (talk) 08:08, 19 June 2013 (UTC)Reply

You are welcome!

edit

I believe at times we learn from sharing thoughts and ideas. I thank you as well for yours... I fear that even if I were an evolved human being, my second brain would not be idling but stuck on something silly as well... Cheers! BillKing (talk) 03:46, 28 June 2013 (UTC)Reply

Ohloh updates

edit

Hello, projects like https://www.ohloh.net/p/mediawiki-extensions-wmf have not been updated in 8 months: do you know of a way to force the update, or can you ask more info on the reasons and what to do to your ohloh contacts? Regards, Nemo 10:27, 24 August 2013 (UTC)Reply

Thanks for noticing! The scan got stuck in three repos for some reason:
I have removed. I will let a scan process the current data and then I will try to add them again. Qgil (talk) 05:05, 25 August 2013 (UTC)Reply
Too bad for those repos, but thanks. Now it says the code for each repo was updated yesterday, but still no updates for the project as a whole. Nemo 14:00, 26 August 2013 (UTC)Reply
There was still
I will be adding the repos again, lets see what happens. Qgil (talk) 15:35, 26 August 2013 (UTC)Reply
With the help or Erik Zachte I went through other proects that had also problems with repos. Now everything listed in Ohloh is updated except four repositories that have been reported at https://www.ohloh.net/forums/10/topics/8539 Qgil (talk) 18:39, 26 August 2013 (UTC)Reply
Great, I see they are already fixing the problem and the Translate re-import is at about 60 % in this moment. Nemo 10:24, 27 August 2013 (UTC)Reply

Template:MediaWiki News

edit

Back in March, you edited Template:MediaWiki News to reformat "the items visible at the homepage" in response to my request on the talk page (thanks). Could you go ahead and change the rest of the items, too? It seems weird to leave it half-done like that. dcljr (talk) 02:17, 9 September 2013 (UTC)Reply

Hi dcljr,
The Qgil requested me to continue this work but I don't have permission to edit this page. Do you know who can give me permission to do that? Thanks in advance. monteirobrena (talk) 14:10, 31 October 2013 (UTC)Reply
Hi monteirobrena, you can do the changes in a subpage under your user page, and I will copy te content from there. Thank you! Qgil (talk) 15:25, 31 October 2013 (UTC)Reply
Just a note to say that monteirobrena completed the little task. Thank you! Qgil (talk) 18:12, 5 November 2013 (UTC)Reply

Google Code-In

edit

Hello,

I've checked with MatmaRex, I'm volunteer to be comentor for the frontend tasks he offers. --Dereckson (talk) 19:24, 30 October 2013 (UTC)Reply

Great! I'm very happy to see you active around. Let's talk if/when we get accepted. Qgil (talk) 19:56, 30 October 2013 (UTC)Reply

RFC review

edit

Thank you for the notification. I posted a question at Talk:Architecture meetings/RFC review 2013-11-06 asking whether there's time to add Requests for comment/Page deletion to the agenda; if not for this meeting, maybe for the next one. It seems like the discussion on that RfC has pretty much petered out, with all arguments having been already presented, so that it's ready for the lead developers to make a decision. The issue was originally brought up 18 May 2010. Aaron S. wants to go with the new table scheme; I think we all can agree that either of the two proposed options would be superior to what we currently have. Thanks. Leucosticte (talk) 04:33, 5 November 2013 (UTC)Reply

The idea is to have RFC reviewed every other week. I'm not an architect but I think the easiest is to propose it for the next meeting at Architecture meetings. Qgil (talk) 18:11, 5 November 2013 (UTC)Reply

Problem in Template:MediaWiki News

edit

Hi, in your edit, you inserted a duplicated #if (with its “Older news” heading), leaving the wikicode visible even on the Main Page (at the bottom of the news box), so you might want to fix that. Mormegil (talk) 16:45, 5 November 2013 (UTC)Reply

Ooops! Thank you very much for the report. Fixed. Sorry, multitasking has its risks. Qgil (talk) 18:09, 5 November 2013 (UTC)Reply

Tech News: 2013-49

edit

08:38, 9 December 2013 (UTC)

MediaWiki message delivery (talk) 08:38, 9 December 2013 (UTC)Reply

Engineering Community Team/Meetings#2013-11-12

edit

In the header, the date of the ECT IRC meeting is stated to be December 11 UTC, but the datetime link says December 10 UTC... Yair rand (talk) 02:32, 10 December 2013 (UTC)Reply

Sorry! The meeting is happening in 12 minutes, Yair rand. Thank you for reporting. See you there? Qgil (talk) 16:48, 10 December 2013 (UTC)Reply

Tech News: 2013-51

edit

08:22, 23 December 2013 (UTC)

MediaWiki message delivery (talk) 08:22, 23 December 2013 (UTC)Reply

Tech News: 2014-01

edit

08:40, 30 December 2013 (UTC)

MediaWiki message delivery (talk) 08:40, 30 December 2013 (UTC)Reply

Tech News: 2014-02

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 08:34, 6 January 2014 (UTC)

MediaWiki message delivery (talk) 08:34, 6 January 2014 (UTC)Reply

Tech News: 2014-03

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 09:33, 13 January 2014 (UTC)

MediaWiki message delivery (talk) 09:33, 13 January 2014 (UTC)Reply

Tech News: 2014-04

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 10:21, 20 January 2014 (UTC)

MediaWiki message delivery (talk) 10:21, 20 January 2014 (UTC)Reply

Tech News: 2014-05

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 09:46, 27 January 2014 (UTC)

MediaWiki message delivery (talk) 09:46, 27 January 2014 (UTC)Reply

How did you move this thread without leaving behind a link to indicate where it should go? TeleComNasSprVen (talk) 10:27, 29 January 2014 (UTC)Reply

Hi TeleComNasSprVen. Honestly, I don't know. Maybe what happened is that I moved it to a page, and then it was moved again from there?
I found it here: Thread:Project:Support_desk/MediaWiki_thumbnails_are_not_being_created#x.5BRESOLVED.5D_Thumbnails_are_not_being_created_38166.
Sorry for the inconvenience. Qgil (talk) 16:43, 4 February 2014 (UTC)Reply

Tech News: 2014-06

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 08:30, 3 February 2014 (UTC)

MediaWiki message delivery (talk) 08:30, 3 February 2014 (UTC)Reply

Tech News: 2014-07

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 09:30, 10 February 2014 (UTC)

MediaWiki message delivery (talk) 09:30, 10 February 2014 (UTC)Reply

Tech News: 2014-08

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 08:38, 17 February 2014 (UTC)

MediaWiki message delivery (talk) 08:38, 17 February 2014 (UTC)Reply

Tech News: 2014-09

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 10:18, 24 February 2014 (UTC)

MediaWiki message delivery (talk) 10:18, 24 February 2014 (UTC)Reply

Tech News: 2014-10

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 09:30, 3 March 2014 (UTC)

MediaWiki message delivery (talk) 09:30, 3 March 2014 (UTC)Reply

GSoC proposals namespace

edit

Hello, about [192], can you please clarify the public documentation at Mentorship_programs/Possible_projects#Where_to_start? I had understood that «one lesson learned is that proposals should be drafted already in pages with correct titles», and the [193] says «Your title should be short, clear and interesting», so using main namespace (without any lengthy User:X/ prefix) or other content namespaces appears to be more effective. Nemo 17:52, 6 March 2014 (UTC)Reply

Replying quickly here for now: the problem with recommending candidates to create their proposals in the Main namespace is that a nice % of these proposals won't make it as a project, and will be abandoned in a few weeks. I think it is better to create these pages in the User namespace, and then move those belonging to accepted projects, when they are accepted. What do you think? The lesson learned points in the direction of pages called "GSoC proposal". Qgil (talk) 08:16, 7 March 2014 (UTC)Reply
"Userfication" of failed proposals however is a common wiki practice. Having them as user pages means making them harder to find for months while they are proposals and are most in need of feedback... In addition finding a home for a project in the wiki is also a way to find a home for the code. Oh well, you decide. Nemo 14:28, 7 March 2014 (UTC)Reply
No, in fact you decide. You are dealing with mediawiki.org more than me, and for a much longer period. You also have a better track than me sorting out GSoC pages. If you think the right thing to do is to create these proposals under Main, then let's do it. Qgil (talk) 15:41, 7 March 2014 (UTC)Reply
Ok, then I've made a couple edits that will hopefully address the issues you mentioned: [194] [195]. You were right that I was perhaps a bit too simplistic, and I'm not saying it will be heaven of course: there may be small conflicts over what pagename to choose or multiple people claiming the same title.
However, it's IMHO worth trying because students really must not work in insolation from the rest of the community and codebase. We don't have enough energies to actively go after each of them to integrate them, we have to "release them in the while" and see what happens. :) Nemo 13:00, 8 March 2014 (UTC)Reply
Nemo_bis, one reason to prepare proposals in your user namespace is that more than one user can apply for the same project idea. If the first one tahes the good title/URL, then the rest are left with weaker options.
There is no need to touch any proposal pages now, but if you agree on the principle then please revert the changes you made.  :) Qgil (talk) 21:02, 21 March 2014 (UTC)Reply
Now that selected projects were announced, it took only 26 minutes to userfy failed proposal and publish successful ones. There were no title clashes (all redirects kept), so I don't think there was big conflict caused by the namespace choice. On the other hand, poorly defined ideas often have bad titles. Nemo 10:03, 22 April 2014 (UTC)Reply
Hello Qgil,
Thanks for the message. I've been thinking about GSoc for a month or so, but I can't really come up with an idea to execute over the summer (much less so through a Wikimedia-based project). My previous couple programming projects have been long-term, interdisciplinary studies between bio and machine learning for EM-image processing, but this does not seem appropriate for a GSoc project. I can try to apply but... I'll need some ideas to ponder and dissect. I only have 2 days though.
Thanks, Hansmeet Thehansmeet (talk) 01:17, 19 March 2014 (UTC)Reply

Tech News: 2014-11

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 09:10, 10 March 2014 (UTC)

MediaWiki message delivery (talk) 09:10, 10 March 2014 (UTC)Reply

Tech News: 2014-12

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 07:14, 17 March 2014 (UTC)

MediaWiki message delivery (talk) 07:14, 17 March 2014 (UTC)Reply

GSoc 2014

edit

Hello Qgil,

Thanks for the message. I've been thinking about GSoc for a month or so, but I can't really come up with an idea to execute over the summer (much less so through a Wikimedia-based project). My previous couple programming projects have been long-term, interdisciplinary studies between bio and machine learning for EM-image processing, but this does not seem appropriate for a GSoc project. I can try to apply but... I'll need some ideas to ponder and dissect. I only have 2 days though.

Thanks, Hansmeet Thehansmeet (talk) 01:16, 19 March 2014 (UTC)Reply

At this point your only choice with Wikimedia is to pick one of the featured project ideas. There is not time to pull out a new project from scratch. Qgil (talk) 22:23, 19 March 2014 (UTC)Reply

GSoC 2014 questions

edit

Hi Quim Gil

I have a couple of questions concerning GSoC.

The problem is I found about it very late, just 5 days before deadline so my proposal is still a bit draft and I've found no mentors yet. The good thing is that the idea hasn't came to me from scratch; I have been working on this since last summer and besides that I am an active member of this community for more than 2 years. That makes me confident that there's still a change for me.

My question is, now that proposals are closed in Google, can I still keep editing my proposal in MediaWiki page? I want to fine tune it, maybe add a couple of more examples, and make a better timeline, because this one was actually in the most part pasted from others' timelines.

My other concern is that I have not a clue where and how to find mentors. You see, all the people I know here are either from the SMW area or from the translation area. So can you give me a hint on this?

Any other advice, remark or tip would be most welcome!

Thanks in advance! Ioannis Protonotarios 15:50, 22 March 2014 (UTC)Reply

Hi Protnet, thank you for reaching out. See my post sent to wikitech-l and forwarded to the Design list. I hope it helps. In the meantime, I recommend you to display you skills by taking related bugs and providing patches, linking to them from your proposal and your entry at Google Summer of Code 2014. You can also consider learning more about the people asking interesting questions about your proposal, finding who are the experts, and inviting them to mentor your project. I will ask around as well. Qgil (talk) 17:45, 22 March 2014 (UTC)Reply

IEG/Magic expression

edit

Hi Quim. Siko (WMF) said that maybe you can help me. Please look at m:Grants talk:IEG/Magic expression#About_eligibility_rules_for_software_development. Pastakhov (talk) 12:43, 23 March 2014 (UTC)Reply

Tech News: 2014-13

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 18:56, 24 March 2014 (UTC)

MediaWiki message delivery (talk) 18:56, 24 March 2014 (UTC)Reply

Tech News: 2014-15

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 08:00, 7 April 2014 (UTC)

MediaWiki message delivery (talk) 08:00, 7 April 2014 (UTC)Reply

Tech News: 2014-16

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 07:18, 14 April 2014 (UTC)

MediaWiki message delivery (talk) 07:18, 14 April 2014 (UTC)Reply

Tech News: 2014-18

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 07:23, 28 April 2014 (UTC)

MediaWiki message delivery (talk) 07:23, 28 April 2014 (UTC)Reply

Tech News: 2014-20

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 06:00, 12 May 2014 (UTC)

MediaWiki message delivery (talk) 06:00, 12 May 2014 (UTC)Reply

edit

I just found out why the sidebar in mediawiki.org isn't collapsing anymore: bugzilla:39035 Waldir (talk) 10:03, 12 May 2014 (UTC)Reply

Tech News: 2014-21

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 07:18, 19 May 2014 (UTC)

MediaWiki message delivery (talk) 07:18, 19 May 2014 (UTC)Reply

Tech News: 2014-24

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 07:39, 9 June 2014 (UTC)

MediaWiki message delivery (talk) 07:39, 9 June 2014 (UTC)Reply

Adding Gerrit project owners

edit

Hello again!

I've authored Extension:UserGroups and I would like to be able to add additional project owners to the extension using https://gerrit.wikimedia.org/r/#/admin/groups/769,members but the "Add" button is greyed out. I thought Gerrit/Project ownership permitted owners to give ownership status to others as well? This is mainly because I'd like to have another person +2 and double-check my code rather than me +2ing changes myself. Do you think you could somehow configure it to allow me to set ownership solely for this extension? TeleComNasSprVen (talk) 19:34, 12 June 2014 (UTC)Reply

Sorry, I had missed this thread. Have you solved the problem? Qgil-WMF (talk) 08:02, 29 August 2014 (UTC)Reply

Tech News: 2014-26

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 07:20, 23 June 2014 (UTC)

MediaWiki message delivery (talk) 07:20, 23 June 2014 (UTC)Reply

Tech News: 2014-27

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 06:53, 30 June 2014 (UTC)

MediaWiki message delivery (talk) 06:53, 30 June 2014 (UTC)Reply

Tech News: 2014-29

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 07:48, 14 July 2014 (UTC)

MediaWiki message delivery (talk) 07:48, 14 July 2014 (UTC)Reply

Tech News: 2014-30

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 07:41, 21 July 2014 (UTC)

MediaWiki message delivery (talk) 07:41, 21 July 2014 (UTC)Reply

Tech News: 2014-31

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 08:09, 28 July 2014 (UTC)

MediaWiki message delivery (talk) 08:09, 28 July 2014 (UTC)Reply

Phabricator migration

edit

Hi. How long is the Phabricator migration going to take? It'd be very nice as I'm losing track of some bugs some Teams (core features team, multimedia team) are working on. (They refuse to file bugs in Bugzilla or use it as primary means of collaboration.) Gryllida 03:50, 25 August 2014 (UTC)Reply

By the end of September -- see Wikimedia_Engineering/2014-15_Goals#Engineering_Community Qgil (talk) 10:00, 25 August 2014 (UTC)Reply
Yeah right. I should have been more considerate and not asked at 3 places. I apologize. Gryllida 04:53, 26 August 2014 (UTC)Reply

Tech News: 2014-43

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 13:47, 20 October 2014 (UTC)

MediaWiki message delivery (talk) 13:48, 20 October 2014 (UTC)Reply

Tech News: 2014-44

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 05:20, 27 October 2014 (UTC)

MediaWiki message delivery (talk) 05:20, 27 October 2014 (UTC)Reply

Tech News: 2014-45

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 17:28, 3 November 2014 (UTC)

MediaWiki message delivery (talk) 17:28, 3 November 2014 (UTC)Reply

Tech News: 2014-46

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:00, 10 November 2014 (UTC)

MediaWiki message delivery (talk) 15:00, 10 November 2014 (UTC)Reply

Tech News: 2014-51

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 16:43, 15 December 2014 (UTC)

MediaWiki message delivery (talk) 16:43, 15 December 2014 (UTC)Reply

Tech News: 2015-03

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 16:47, 12 January 2015 (UTC)

MediaWiki message delivery (talk) 16:47, 12 January 2015 (UTC)Reply

Tech News: 2015-04

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 18:12, 19 January 2015 (UTC)

MediaWiki message delivery (talk) 18:12, 19 January 2015 (UTC)Reply

Events/FOSDEM/2015

edit

Events/FOSDEM/2015 is on the road and in our topic for the first General assembly of Wikimedia Belgium this Saturday. Let's start to manage the wikimedia stand. Cheers, Lionel Scheepmans (talk) 18:10, 20 January 2015 (UTC)Reply

Hi Lionel_Scheepmans! Thank you for driving this. See also phab:T84971. Qgil-WMF (talk) 03:19, 24 January 2015 (UTC)Reply

Tech News: 2015-05

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 16:08, 26 January 2015 (UTC)

MediaWiki message delivery (talk) 16:08, 26 January 2015 (UTC)Reply

Tech News: 2015-07

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 16:26, 9 February 2015 (UTC)

MediaWiki message delivery (talk) 16:26, 9 February 2015 (UTC)Reply

Tech News: 2015-08

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 17:57, 16 February 2015 (UTC)

MediaWiki message delivery (talk) 17:57, 16 February 2015 (UTC)Reply

Tech News: 2015-10

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 16:41, 2 March 2015 (UTC)

MediaWiki message delivery (talk) 16:41, 2 March 2015 (UTC)Reply

Tech News: 2015-13

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:09, 23 March 2015 (UTC)

MediaWiki message delivery (talk) 15:09, 23 March 2015 (UTC)Reply

Tech News: 2015-14

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:18, 30 March 2015 (UTC)

MediaWiki message delivery (talk) 15:18, 30 March 2015 (UTC)Reply

Tech News: 2015-15

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:41, 6 April 2015 (UTC)

MediaWiki message delivery (talk) 15:41, 6 April 2015 (UTC)Reply

Tech News: 2015-16

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 16:40, 13 April 2015 (UTC)

MediaWiki message delivery (talk) 16:40, 13 April 2015 (UTC)Reply

Tech News: 2015-17

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:29, 20 April 2015 (UTC)

MediaWiki message delivery (talk) 15:29, 20 April 2015 (UTC)Reply

Tech News: 2015-18

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:10, 27 April 2015 (UTC)

MediaWiki message delivery (talk) 15:10, 27 April 2015 (UTC)Reply

Support request with team editing experiment project

edit

Dear tech ambassadors, instead of spamming the Village Pump of each Wikipedia about my tiny project proposal for researching team editing (see here: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Research_team_editing), I have decided to leave to your own discretion if the matter is relevant enough to inform a wider audience already. I would appreciate if you could appraise if the Wikipedia community you are more familiar with could have interest in testing group editing "on their own grounds" and with their own guidance. In a nutshell: it consists in editing pages as a group instead of as an individual. This social experiment might involve redefining some aspects of the workflow we are all used to, with the hope of creating a more friendly and collaborative environment since editing under a group umbrella creates less social exposure than traditional "individual editing". I send you this message also as a proof that the Inspire Campaign is already gearing up. As said I would appreciate of *you* just a comment on the talk page/endorsement of my project noting your general perception about the idea. Nothing else. Your contribution helps to shape the future! (which I hope it will be very bright, with colors, and Wikipedia everywhere) Regards from User:Micru on meta. MediaWiki message delivery (talk) 09:32, 30 April 2015 (UTC)Reply

Tech News: 2015-19

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:04, 4 May 2015 (UTC)

MediaWiki message delivery (talk) 15:04, 4 May 2015 (UTC)Reply

Tech News: 2015-20

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:34, 11 May 2015 (UTC)

MediaWiki message delivery (talk) 15:34, 11 May 2015 (UTC)Reply

Tech News: 2015-21

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:19, 18 May 2015 (UTC)

MediaWiki message delivery (talk) 15:19, 18 May 2015 (UTC)Reply

Tech News: 2015-22

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 16:15, 25 May 2015 (UTC)

MediaWiki message delivery (talk) 16:15, 25 May 2015 (UTC)Reply

Tech News: 2015-23

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:35, 1 June 2015 (UTC)

MediaWiki message delivery (talk) 15:35, 1 June 2015 (UTC)Reply

Tech News: 2015-27

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:56, 29 June 2015 (UTC)

MediaWiki message delivery (talk) 15:56, 29 June 2015 (UTC)Reply

Tech News: 2015-27

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 18:53, 29 June 2015 (UTC)

MediaWiki message delivery (talk) 18:53, 29 June 2015 (UTC)Reply

Tech News: 2015-27

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 20:13, 29 June 2015 (UTC)

MediaWiki message delivery (talk) 20:13, 29 June 2015 (UTC)Reply

Tech News: 2015-28

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 15:13, 6 July 2015 (UTC)

MediaWiki message delivery (talk) 15:13, 6 July 2015 (UTC)Reply

Tech News: 2015-28

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 16:44, 6 July 2015 (UTC)

MediaWiki message delivery (talk) 16:44, 6 July 2015 (UTC)Reply

Tech News: 2015-28

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end /> 18:30, 6 July 2015 (UTC)

MediaWiki message delivery (talk) 18:30, 6 July 2015 (UTC)Reply

Talk:Wikimedia Developer Summit 2016

edit

Unfortunately Flow does not allow me to add a comment to this page so I am unable to continue our discussion about whether the conference is insular. Rogol Domedonfors (talk) 20:57, 17 September 2015 (UTC)Reply

Hi @Rogol Domedonfors, not perfect but good enough: Topic:Sp573ryponvhr8jk. Qgil-WMF (talk) 09:16, 18 September 2015 (UTC)Reply

WMF-Community engagment

edit

It's fine if you don't reply right away, enjoy the holidays :)

I mentioned here that there were two issues where I had unsuccessfully tried to get WMF engagement. The first one was regarding the Workflow project. (It currently appears to be in limbo, so there's no rush here.) There was an announcement that the WMF wanted to start working on it. I looked into the available info and the general concept is great. I think the community could potentially be very happy with it. One of the preliminary sketches looks like it would provide an awesome replacement for things like Twinkle. However I spoke with the (former) project manager and I'm concerned with the planned project direction. He indicated that it would be a Flow project, and that it would "not serve" communities or workflows that didn't switch to Flow. I believe the community would strongly want a system that supports existing pages, a system which might be compatible with Flow pages if/when/where we find Flow pages useful. The manager and liaison were less than enthusiastic with my suggested project direction. They were less than enthusiastic when I asked about an RFC on the subject. They were less than enthusiastic when I asked if they would pay attention to cross-wiki RFC's representing a majority of the global community. You can see the current situation here. The project manager was transferred and the liaison promised me a response. I tried for weeks, and got nothing. I think(?) I posted an extremely reasonable request there.

It's not currently an active project, I wasn't expecting it to go silent for two months, but the whole point was to seek community input on project-direction before things get to the development phase. The earlier the better. My biggest concern is that the WMF was actively averse to the idea of community input.

Do you think my request there was a good model for WMF-Community engagement? Can WMF processes and culture shift to actively invite community input before stuff starts getting built? I wasn't even asking for a specific outcome on the Workflow issue - I was asking for the WMF to be open to discussion on project planning. Announce a project idea, and if there are concerns then we discuss it. Alsee (talk) 14:27, 25 December 2015 (UTC)Reply

Hi @Alsee, thank you for reaching out and for bringing that thread to my attention. I don't think anybody in that discussion was/is averse to community input. When you have no new information (because the question is complex and you are working on something else) one option is not to force yourself to provide a half-baked answer, or an answer based on premature assumptions that might turn out to be not true in the future.
Being silent while developing a big new feature set like Workflows would be bad indeed, but as you can see that development is not happening yet. In terms of product development process, they are still in the Concept stage, no plans to request prioritization and enter the Plan stage. The team wants to do proper research, including engagement with our communities, when the right time comes.
Let's continue in that thread? Qgil-WMF (talk) 22:56, 28 December 2015 (UTC)Reply
The... erm...apparent disinterest in community input... was in particular on the former project manager's talk page, prior to that thread. Where I was told that an RFC was not needed, apparently not wanted, and I got the impression that the impression that the possibility of a majority global community view was not warmly received.
I'll continue that there, but I'll post the second issue here later. My brain is too tired to give it due care right now. Alsee (talk) 23:12, 28 December 2015 (UTC)Reply
Hi @Alsee, I'm the new PM for the Collaboration team. Pleased to meet you, and thanks for giving a push on this important body of work. As @Quiddity (WMF) noted in your other thread, this is very much in the early stages. Right now, the team is focused on bringing out a raft of new Notification features. I'm focusing on that and on getting up to speed with everything the Editing team has been working on. So as @Qgil-WMF says, it's very early days. From what I can see, there's a lot of interest in taking a hard look at everything connected with Flow. As we do that and begin to focus more on Workflows, I'll look forward to collaborating with and getting lots of input from you and others in the community. Thanks for reaching out. JMatazzoni (WMF) (talk) 21:01, 29 December 2015 (UTC)Reply
JMatazzoni (WMF) , I don't feel my question has been answered. You're still referring to Workflow as connected to Flow. The latest discussion about Flow at En-VillagePump was unanimously opposed to Flow.
If there is a demonstrated community consensus, could the community change the project direction to be completely independent of Flow? Alsee (talk) 19:16, 5 January 2016 (UTC)Reply
Please don't discuss Flow (or any important topics) in my Talk page. Do it in the corresponding project pages instead, where the interested people is watching and can participate better. Qgil-WMF (talk) 15:50, 10 January 2016 (UTC)Reply
That is an excellent point.
I've been trying to get an answer to this at Talk:Collaboration/Workflows for months. I replied here because this is where JMatazzoni replied. I would be eager to see my question to be answered over there. Alsee (talk) 22:26, 10 January 2016 (UTC)Reply
As far as I know, the team is working on a good reply, not only to your specific question, but to the whole puzzle. It is time to discuss strategy and time to define a solid mid term plan. Qgil-WMF (talk) 02:51, 14 January 2016 (UTC)Reply
Hi. What I'm really trying to get at is your Project Manager approach to community engagement. (That's the topic title here, grin.) The WMF should disregard input from me or other individuals at will. Any random yahoo with fringe or dumb ideas can make an account. But the community should be a partner. A consensus is the community position.
I believe the community in general isn't going to like the idea of a Flow-based-Workflow. We have been eliminating the few Flow boards we do have, and we'll probably be Flow-Free soon. If you want to draft the concept and benefits, and pitch the idea to the community pre-build, sure. Maybe I'm wrong about the Community view, maybe you've got some great concept with valuable benefits.
On the other hand if I'm right, if there is an English wiki consensus (or consensus at English + other wikis representing a majority of the global community), and that consensus is against the Flow-based design, do you agree that it would be a bad idea to build something that the community doesn't want? Alsee (talk) 22:45, 29 December 2015 (UTC)Reply

Please provide feedback on suggested improvements to the Code of Conduct

edit

Thanks to everyone who’s helped work on the Code of Conduct so far.

People have brought up issues they feel were missed when working on "Unacceptable behavior" and "Report a problem". Consultants have also suggested changes in these same sections.

These are important sections, so please take a look at the proposed changes. I apologize that this feedback arrived later than planned, but I think this will create a better document.

If you prefer to give your opinion privately, feedback via e-mail is welcome at conduct-discussion wikimedia.org.

Thanks. Mattflaschen-WMF via MediaWiki message delivery (talk) 04:18, 24 February 2016 (UTC)Reply

Please participate in discussion on updated "Marginalized and underrepresented groups" text

edit

Thanks for participating in the earlier discussion on Talk:Code of Conduct/Draft#Marginalized and underrepresented groups. There was some support and some issues were raised. I've attempted to propose a better draft to address the issues.

Please participate at Talk:Code of Conduct/Draft#New proposed wording. Thanks. User:Mattflaschen-WMF via MediaWiki message delivery (talk) 01:40, 17 March 2016 (UTC)Reply

Please participate in discussion on updated "Enforcement issues" text

edit

Thanks for participating in the earlier discussion on Talk:Code of Conduct/Draft#Enforcement issues. There was strong support for the first two points, so they have been closed. Most people either supported the third at least in principle, or were neutral. However, there are some suggested wording changes (partly by Smalyshev (WMF), and partly by me).

Please participate again at Talk:Code of Conduct/Draft#New proposed wording. Thanks. User:Mattflaschen-WMF via MediaWiki message delivery (talk) 01:48, 17 March 2016 (UTC)Reply

Please participate in discussion on updated "Enforcement issues" text

edit

Sorry, the correct link for the discussion about wording re Talk:Code of Conduct/Draft#Enforcement issues is Talk:Code of Conduct/Draft#Circumvention text new wording. Thanks. I apologize for the double-message. User:Mattflaschen-WMF via MediaWiki message delivery (talk) 01:51, 17 March 2016 (UTC)Reply

Remote coordination for Wikimedia Hackathon

edit

Hi, Quim, regarding phab:T120788 recommended for the Israel hackathon, can you please give me some info about the remote coordination (mode, timing, any video conference etc.) The developer of the project will not attend the event in person, and so we need to arrange remotely. Bodhisattwa (talk) 15:48, 31 March 2016 (UTC)Reply

Oh Jesus it's here too

edit

I was coming to this talk page to discuss how to remove Flow from Talk:Wikipedia.org add mobile app badges and now I notice it's here as well. :-( Flow is really quite bad. Is there a way remove Flow from talk pages? Is it now the default for new talk pages here? I really don't think we should be making users suffer this, even on a more technical wiki such as mediawiki.org. MZMcBride (talk) 01:01, 18 June 2016 (UTC)Reply

Hi, yes, Flow has been the default for new pages in mw.o for a while now. I actually have nothing to do with this, even if as a user of mw.o I agree with this decision. This is a site welcoming technical novelties and software looking for testing, feedback, and improvements.
I disagree with your assessment about Flow, and I enjoy using it over wikitext discussion pages. I especially like the possibility to select the topics of a discussion page I want to watch, and the fact that indentations are made automatically (I wonder why in 2016 I need to count colons to post a reply, especially in comments with bullet points). In my experience here and in ca.wiki, I believe the "suffer" you describe is caused more by political reasons than purely technical, but that is just my personal opinion. I think newcomers and most of the regular editors enjoy Flow better all in all, and one of my priorities is to make life easier for newcomers. Veterans can adapt, and for instance in ca.wiki they do adapt because there they also share a priority on the newcomers' experience over their veteran love for wikitext everywhere.
It's a matter of priorities, perspectives and flexibility, I guess. Qgil-WMF (talk) 08:50, 18 June 2016 (UTC)Reply

A barnstar for you!

edit
  The Original Barnstar
I enjoyed reading your presentations on ways to improve Wikimedia through software. Julianharty (talk) 14:34, 30 August 2016 (UTC)Reply

Please participate again in improving the "Conflict of interest" section

edit

The "Conflict of interest" section was not approved earlier.

There has been further discussion on it, aiming to solve those issues. Please participate in the sub-sections of Talk:Code of Conduct/Draft#Finalize "Conflict of interest" section? and make sure your concerns are being addressed.

Thanks.

User:Mattflaschen-WMF 03:55, 28 September 2016 (UTC) MediaWiki message delivery (talk) 03:55, 28 September 2016 (UTC)Reply

Tech News: 2016-10

edit

<labeledsectiontransclusion/begin />

<labeledsectiontransclusion/end />

MediaWiki message delivery (talk) 15:07, 17 October 2016 (UTC)Reply

Collaboration products newsletter: 2016-11

edit

16:32, 16 November 2016 (UTC)

MediaWiki message delivery (talk) 16:32, 16 November 2016 (UTC)Reply

Weigh in on whether to finalize the new version of the "Conflict of interest" section

edit

You participated earlier in discussion about the "Conflict of interest" section of the draft Code of Conduct for technical spaces. There was not consensus to approve an earlier version of this section. I'm contacting you to let you know the draft has been updated, and we are now discussing whether to finalize the new version.

Please participate here.

Thank you,

User:Mattflaschen-WMF via MediaWiki message delivery (talk) 04:32, 24 November 2016 (UTC)Reply

Collaboration products newsletter: 2016-12

edit

10:08, 19 December 2016 (UTC)

MediaWiki message delivery (talk) 10:08, 19 December 2016 (UTC)Reply

A test of the Technical Collaboration Guideline

edit

In the Metawiki proposal to remove Flow,[709] you suggested treating it as a test for the TCG.

I don't think that case is really much use as an effective test. I think the collaboration guideline is about to face a real test. I wanted to let you know in advance, and I invite any thoughts you have on it.

The situation:

The WMF decided to build a new Wikitext Editor. It is currently available as an opt-in beta test feature. According to the plan, in a few months it would become the default wikitext editor. The current editor would temporarily remain as an opt-in option, but eventually it would be removed.

There are currently a big pile of bugs on the project. And of course that's normal and fine. I'm not concerned about them. I have full confidence that our devs will do an excellent job addressing the routine issues. I'm also confident that the WMF isn't going to try to move it out of beta until those routine issue are resolved to a high quality.

However I believe there are two "non-routine" issues. Several editors have told the WMF that these are significant issues. 100% of the (non-staff) comments on the issues agree that they are significant issues. Most of those comments explicitly identified the issues as severe enough to disqualify the project from deployment as the default editor.

I opened a topic on each issue, each topic explicitly stating that the issue should be categorized as an actionable blocker. That statement was in the body of the comment. In retrospect, I probably should have put that in the title of the topic, and I probably should have explicitly mentioned that they were intended as TCG-actionable-blockers. Staff on the project do not seem to have made the connection, and they do not seem to have placed any special significance on them.

Staff have acknowledged the basic validity of the concerns. However the two issues would be either very difficult, or virtually impossible to resolve, given the fundamental plan and design of the project. The response of the staff has basically amounted to "oh well, we can't/won't fix them, and we don't consider them very important".

This is where things always run into trouble. The WMF is great at bugfixes and enhancement requests. But when an issue can't be resolved within the pre-defined project plan, staff deal with it as politely as they can and they just go back to work. And if it's just one person with a dumb issue, that's fine. But then a second editor says this issue disqualifies the project from deployment, and they are politely dismissed. Then the third editor is politely dismissed. Then the fourth editor is politely dismissed. And the project just keeps rolling forwards. Then phases like "talking to a brick wall" start to become common vocabulary in the community.

When you have random individuals showing up with assorted comments, I understand it can be hard to sort out the important issues from the unimportant-individual-fluff. I think part of the problem here is that, for most staff, the only time they encounter an RFC is when it looks like a giant catastrophic meteor falling from the sky. In the community, RFCs are an important, useful, and routine tool. If someone posts on a project page saying they think a project shouldn't be deployed because (issue), I think it would be great if the response was something like this:

That's a hard issue. I don't think that's something we can/will fix. But we will certainly escalate the issue if you point us to a community consensus saying it's really that severe.

Result: The person knows they were heard. They were offered a constructive avenue to pursue their concern. And they have effectively been told to go away.... in the most positive and polite possible meaning of that phrase. Either they drop the non-issue, or the community shoots down their non-issue, or they come back with a consensus saying yes, this really is something important.

The last thing most staff want to do is invite someone to run an RFC, but it really is an excellent way to deal with the community. If the person is a pest ranting about a non-issue, the community will deal with them. If the person is genuinely representing the community view, if the issue really is as important as they're claiming, then that is an issue the project team needs to deal with whether they like it or not. Effectively inviting an RFC in the early stages is far better than a meteor-from-the-sky at deploy phase.

I got rather sidetracked in the last few paragraphs.... but I think it was a good sidetrack. Anyway, back to the two Actionable Blocker issues at hand:

Issue 1: Previews

edit

The New Wikitext Editor does not provide genuine article previews. The "new editor" is actually being designed as a new mode within the Visual Editor extension. The "new editor" actually uses the VE software-stack to generate previews. This means that there's a vast number of things that render differently in the preview than when the page is actually saved.

Project team's perspective (as I understand it)

edit

There have always been all sorts of things that don't display correctly in VE, but it's never been a major issue before so long as it gets most things right. VE is awesome, it's the Future Of Wikipedia, it is the long term plan, everything should move in that direction.

Community perspective (as I understand it)

edit

VE is a secondary editor, used by almost no one. (About 95% of all edits are wikitext edits.) VE's goal was to make editing easier and bring in new people. VE failed that goal. The WMF's own research shows that VE helped an additional 0% of new users to successfully make a first edit. The research also shows it produced a 0% increase in editor retention, and 0% increase in total contributions. Almost everyone uses wikitext because it's simply a better tool for the job.

No one complains about rendering issues in VE because it's a secondary editor, because we understand VE was a difficult project to build, and because anyone who chooses to use VE is choosing to accept any warts that come with it.

We already have an excellent wikitext editor. It already gives 100% accurate previews. The essential purpose of previews is accuracy. Preview errors will frustrate experienced editors and confuse new editors. Replacing accurate previews with broken previews is an obvious downgrade. The team has stated that some of the rendering errors are CANTFIX/WONTFIX. There are currently a ton of serious rendering issues the team does intend to fix, but even if the team fixes a hundred bugs, even if the errors only show up in rare or weird cases, it's just plain dumb to break previews. Many people won't care if the project is aiming for "99+%" accuracy. The blocker here is that the the WMF stop trying to play whack-a-mole fixing most of the endless preview-bugs. The blocker is to provide genuine article views, using the genuine article view engine. That fixes 100% all at once.

Many people are going to be hostile. The view will be that the WMF is breaking our PRIMARY editor... and people will think it's because the WMF's obsession with VE is becoming pathological.

I know everyone at the WMF has good intentions, but the WMF's perspective and priorities sometimes don't quite parallel the perspectives, priories, and experience of editors. Good intentions tend to fall to the wayside when it seems like things are being broken for bad reasons.

Issue 2: Load time

edit

With the current wikitext editor it only takes three seconds before I can begin editing a large and important article like United States.

With the current wikitext editor it only takes five seconds before I can begin editing our largest article.

The New Wikitext Editor is actually a new mode in VE. It requires far more code, it's a memory hog, and I think(?) that it has to spend time analyzing the wikitext before it can do anything.

With the New Wikitext Editor I have to wait thirty seconds before I can begin editing the United States article.

When I try to edit our largest article with the New Wikitext Editor, I'm stuck sitting here staring at my clock for one hundred and twenty seven seconds before I can begin editing.

I don't know if my time measurements will be typical for other people. However the issue is obvious, even if most people get better times than I do.

The perspectives on this issue will be essentially the same as before. For the VE team, slow load times are an accepted fact. No one ever screamed that it was a fatal problem for VE. For the community, slow load times are simply one of the warts that comes along with VE. If you don't like the VE's load time, then don't use VE.

And here too, people are going to get hostile. An editor that takes 30 seconds to load is BAD, an editor that can take 127 seconds to load is absolutely obscene. People will ask why is the WMF screwing up our primary editor? Some people will feel that the WMF's obsession with VE has become pathological, some people will feel that the WMF's disdain for wikitext is bordering on deliberate sabotage.

I first raised the preview issue three months ago, when the very first prototype was available on the test servers. Someone else first raised the load time issue two months ago. Multiple editors have said these issues BLOCK deployment. I explicitly said they should be categorized as "actionable blockers". So we're at the next step. I am in the middle of drafting an RFC to file a formal block against deployment (subject to finding a resolution, of course). I anticipate the RFC is going to pass overwhelmingly. Based on what I know about the project, I don't think these issues can be fully resolved without substantially scrapping the design. Alsee (talk) 20:16, 4 January 2017 (UTC)Reply

Almost every time that I have attempted to bring the TCG to a conversation about an ongoing project I have surprised / confused / annoyed someone, so I have decided to stop mixing both concepts unless the conversation is happening in a social context over drinks (or similar), as a purely mental and open-minded exercise.  :) I guess you have seen my recent comment about this at Meta:Babel.
If you want to propose blockers for the new wikitext editor, I recommend you to document them as tasks blocking T142523. Maybe the issues you are reporting here have already their own tasks? If not, feel free to create them. That is the best way to assure that they will not be missed by the development team or other users interested in the new wikitext editor, since any steps forward for that product will eventually pass through that funnel. That is also where it will be decided which tasks are considered blockers indeed, and which are considered non-blocking problems, no-problems... Qgil-WMF (talk) 10:06, 7 January 2017 (UTC)Reply
My electricity dropped out and I need to start the RFC draft from scratch :(
In the mean time, I opened the two Phabs you suggested. T154843 and T154844. I don't have high hopes, but I assume the mention of RFC and potential deployment block will draw attention. Alsee (talk) 12:00, 7 January 2017 (UTC)Reply
Update:
It's been 9 days since I submitted the two Phab items. Neither has been accepted, neither has been rejected, no one on the project has addressed either issue in any fashion. I wish I could say I expected a more productive result. :(
I opened the RFC: Proposal_to_submit_blockers_on_replacing_our_wikitext_editor.
Aside from opening the RFC weeks ago, is there anything I should have done differently? Alsee (talk) 00:40, 17 January 2017 (UTC)Reply
Since you submitted the Phabricator items there has been a Wikimedia Developer Summit and a Wikimedia Foundation AllHands meeting that has kept many of us busy. Also, why the urgency? Qgil-WMF (talk) 02:51, 17 January 2017 (UTC)Reply
Urgency? We've been trying to get a constructive response from the project team for ~15 weeks on previews, and for ~11 weeks about load time.
The WMF is great at bug fixes and enhancement requests, but a certain pattern kicks in when an issue cannot be easily resolved within the predefined plan. For example fixing previews would require a fundamental design change. The issue is raised, saying that it's going to block deployment. It gets a polite and completely non-committal response. "Um yeah.... mumble mumble mumble". I'm not sure if people are trying too hard to be "polite" and not say "no", but they either can't or won't change the core plan and the issue just falls down the memory-hole without a meaningful response. Multiple people try to raise the issue multiple times, saying this will block deployment, and it never gets a "yes" or "no" or any other sort of resolution. The issue just keeps disappearing into the page history. The project train just keeps rolling forwards. The WMF just keeps digging itself into a deeper and deeper hole. More and more $$$ and dev-hours are piled on. Then the WMF is predictably surprised when there are problems at deployment phase. "OMG, we've spent all this time and money, and the community is battling us at the last minute."
I didn't know about the Developer Summit and stuff, and I know 9 days isn't a particularly long time up on Phab. But everyone up to and including JDForrester has known about this issue for months, and has been blowing off the issue for months. The only reason I waited the extra 9 days is because you suggested giving Phabricator a shot. There was no acceptance, no rejection, not a single comment indicating that anyone was evaluating it as a critical issue.
The earlier an issue is caught and addressed, the easier, cheaper, and less stressful it is to resolve. I regret that I didn't run the RFC 10 or more weeks ago. It would have helped the WMF to genuinely take note of the issue before investing so much time and money.
What I'd really like is to reach a place where an RFC isn't viewed as some evil combative thing. Where you don't think I was hasty running the RFC now, where the RFC would have been welcome 10 weeks ago. A place where an RFC has one of two positive outcomes. Either the community shoots down unreasonable objections for you (win), or the RFC brings you important and desired information about the project as early as possible (win). Alsee (talk) 14:23, 18 January 2017 (UTC)Reply
The new wikitext editor is an opt-in beta feature in English Wikipedia. Discussion of potential problems of performance and previews belong to this stage. As far as I am aware, nobody is talking about graduating this beta. This is why I don't share your sense of urgency. Qgil-WMF (talk) 09:41, 19 January 2017 (UTC)Reply
I don't see the issue as "urgent". I merely see it as overdue.
The worst time to address issues is when perpetual inaction drags out to deployment phase. So far the inaction has dragged out for ~15 weeks, despite repeated attempts by multiple editors to obtain a meaningful response.
The best time to address issues is as early as possible, ideally before any time and money is invested in coding. I tried to do exactly that, before a test version even existed. I was informed that there was no information available and that I had to wait until it was built. So we missed the best opportunity. After a prototype is built, the earlier issues are addressed the less costly and disruptive it is to the development process. If there is a change to the plan, it benefits the WMF to know that as early as possible. Alsee (talk) 21:07, 19 January 2017 (UTC)Reply
I think we are starting to repeat ourselves.
I thank you for submitting your proposals for blockers in Phabricator, connected to the right task. This is the most efficient way to assure that your reports are addressed.
Once the problems are reported... is there a benefit in insisting on them on a daily basis? If your ultimate goal is to help the development team releasing the new software with those problems resolved, then I don't think so.
The team is not inactive at all. You can check their priorities here. Qgil-WMF (talk) 09:20, 20 January 2017 (UTC)Reply
Also, can it be that you haven't linked to the Phabricator tasks you opened from your RfC? You got some feedback in both, and people interested in your RfC might be interested in those conversations. Qgil-WMF (talk) 02:57, 17 January 2017 (UTC)Reply
Thanx. Good idea. I added Phab links to the RFC. Alsee (talk) 14:25, 18 January 2017 (UTC)Reply
It looks like I was right, this is a real test case for collaboration.
I assume the team will make a good faith effort to look into the load time issue (T154843), although I question whether they can realistically reduce the time to be similar to the current editor. But let's set that aside.
Jdforrester has categorized the other consensus-blocker as "invalid" (T154844). Do you have any suggestion on how we should proceed? Alsee (talk) 20:09, 25 March 2017 (UTC)Reply
That task is still open and the conversation is continuing there. Qgil-WMF (talk) 06:44, 27 March 2017 (UTC)Reply

Collaboration products newsletter: 2017-02

edit

09:40, 14 February 2017 (UTC)

MediaWiki message delivery (talk) 09:40, 14 February 2017 (UTC)Reply

Collaboration products newsletter: 2017-03

edit

17:02, 20 March 2017 (UTC)

MediaWiki message delivery (talk) 17:02, 20 March 2017 (UTC)Reply

A barnstar for you!

edit
  The Original Barnstar
For your enormous good works so far. You are really a source of my inspiration to be honest. Thanks for your guidance and lead :) Alangi derick (talk) 23:42, 1 April 2017 (UTC)Reply

Collaboration products newsletter: 2017-05

edit

15:19, 16 May 2017 (UTC)

MediaWiki message delivery (talk) 15:19, 16 May 2017 (UTC)Reply

Collaboration products newsletter: 2017-06

edit

08:41, 23 June 2017 (UTC)

MediaWiki message delivery (talk) 08:41, 23 June 2017 (UTC)Reply

Collaboration products newsletter: 2017-07

edit

16:43, 24 July 2017 (UTC)

MediaWiki message delivery (talk) 16:43, 24 July 2017 (UTC)Reply

Newsletter y descripciones que no soportan wikitexto

edit

Hola Quim:

¿Existe ticket en Phabricator para Newsletter:Newsletter²?

Me refiero a que, como verás, aunque intentes dar formato a la descripción de la newsletter, se muestra todo como texto plano.

Aprovecho la ocasión para saludarte. Espero que estés bien.

Un saludo. —MarcoAurelio (talk) 21:39, 9 September 2017 (UTC)Reply

Hola de nuevo. He creado un ticket en Phabricator en relación a este asunto. Un saludo. —MarcoAurelio (talk) 18:50, 10 September 2017 (UTC)Reply
Hola @MarcoAurelio, muchas gracias por tu continuo interés en mejorar esta extensión. Acabo de responder en Phabricator. Qgil-WMF (talk) 19:58, 10 September 2017 (UTC)Reply
Sí, lo he visto. Gracias a tí por la ayuda. Me gusta newsletter, creo que tiene un gran potencial. Un saludo. —MarcoAurelio (talk) 20:14, 10 September 2017 (UTC)Reply

Global Collaboration products newsletter: 2017-11

edit

15:36, 21 November 2017 (UTC)

MediaWiki message delivery (talk) 15:36, 21 November 2017 (UTC)Reply

Global Collaboration products newsletter: 2017-12

edit

14:31, 19 December 2017 (UTC)

MediaWiki message delivery (talk) 14:31, 19 December 2017 (UTC)Reply

Global Collaboration products newsletter: 2018-01

edit

00:56, 25 January 2018 (UTC)

MediaWiki message delivery (talk) 00:56, 25 January 2018 (UTC)Reply

Collaboration products newsletter: 2018-02

edit

11:29, 5 March 2018 (UTC)

MediaWiki message delivery (talk) 11:29, 5 March 2018 (UTC)Reply

Collaboration products newsletter: 2018-03

edit

12:25, 26 March 2018 (UTC)

MediaWiki message delivery (talk) 12:25, 26 March 2018 (UTC)Reply

Support Low-Budget Wikis

edit

Hi

Hope you're the right person to contact. Found your info through these pages, suggested by somebody on phabricator.

I'm building a wiki on a shared webhost, who doesn't support node.js.

gunretort.xyz

Of course i love the new VisualEditor, but without node.js, we cannot use it.

Meantime, WikiEditor is really showing it's age. Other wysiwyg editors, like TinyMCE, CKEditor, etc are buggy or no longer supported (mostly the latter).

I strongly believe MediaWiki's social mission compels you to support low-budget wikis. But if WikiEditor continues to be lame and neglected, while VisualEditor gets all the attention, then you're being elitist, and neglecting MediaWiki's social mission.

Looking forward to your reply.

Thx,

Johny Why Johnywhy (talk) 05:40, 14 April 2018 (UTC)Reply

Hi, I have been thinking about your question and what comes is my personal answer. I am not "the right person to contact" but maybe I can help you.
When it comes to low-budget projects, I think the question to be asked is not why depending on JavaScript or node.js to offer a good user experience, but why self-hosting. Running your own server is going to be resource intensive always (where resource includes not only money, also time). Meanwhile, MediaWiki's strength is to be run in a wiki farm (because Wikimedia is at the end a huge wiki farm).
There are wiki farms out there offering free wikis, also with VisualEditor and/or decent editors. Would this be an option for you? Qgil-WMF (talk) 09:55, 19 April 2018 (UTC)Reply
If it's configurable as I need, and going to exist for years, then yes.
I tried the following for a while, and it wasn't bad.
https://meta.miraheze.org/wiki/Miraheze
But self-hosting offers more of the options I need, and I know it's not going anywhere.
Note, running a private server is resource intensive, as you mentioned. But shared hosting is less so.
Thx Johnywhy (talk) 11:56, 19 April 2018 (UTC)Reply
With JavaScript spreading all over and with virtual hosting prices falling, I wonder whether using JavaScript is equivalent to "being elitist", and whether low-cost really is really equivalent to no JavaScript.
When it comes to the Wikimedia Foundation, the priority is to improve the user experience of editors, including those without the luxury of a desktop or high bandwidth. Plans go in the direction of offering a better mobile editing experience, because for millions of people low-cost really means regular access to mobile but less so to a desktop.
I guess this explains why the Foundation is investing in VisualEditor and mobile editing via web and native apps, and why there are no plans to develop the legacy editors further.
But anyway, as said all these are just my personal opinions. My talk page and myself are in fact not the best to provide the best informed answer. If you want to discuss this further, I recommend you to do it directly with the developers at the wikitech-l mailing list. Qgil-WMF (talk) 09:05, 20 April 2018 (UTC)Reply

Alterar Página Principal

edit

Olá amigos,

Preciso alterar a página principal utilizada pelo sistema, ao abrir preciso que chame uma página especifica e não a página principal.

Também gostaria de saber se há a possibilidade de alteração do nome de uma página já criada. Caio martins2011 (talk) 19:50, 16 April 2018 (UTC)Reply

Hi, see
I solved the problem with your tip. Thank you very much. Caio martins2011 (talk) 13:37, 17 April 2018 (UTC)Reply

Extensão para relatório de acessos

edit

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Bom dia amigos.

Preciso saber quantos acessos foram realizados por página. Existem alguma extensão que faça isso? Caio martins2011 (talk) 13:38, 17 April 2018 (UTC)Reply

Hi, this is just my personal Talk page. If you have more questions, please ask in Project:Support desk, where others will be able to help as well. Thank you. Qgil-WMF (talk) 13:45, 17 April 2018 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Latest message for Collaboration team newsletter; Growth team's newsletter invite

edit

Hello

Sorry to use English if that's not your favorite language.

You are receiving this message because you were reading the Collaboration team newsletter.

The Collaboration team doesn't longer exists. That team was working on building features that encourage collaboration. This is the latest message for that newsletter.

The Growth Team, formed in July 2018, supports some former Collaboration projects. The Growth Team's main objective is to ease new editors' first steps on wikis, through software changes. You can discover all objectives and missions of the Growth team on its page.

If you wish to be informed about Growth team's updates about easing new users first steps, you can subscribe to the new list to get updates. The first message from Growth –with a call for feedback on a new project– will be posted in a few days!

If you have questions or you want to share experiences made on your wiki about new users' first steps, please post them on the team talk page, in any language.

On behalf of the Growth team, Trizek (WMF) (talk) 10:29, 22 August 2018 (UTC) MediaWiki message delivery (talk) 10:29, 22 August 2018 (UTC)Reply

How we will see unregistered users

edit

Hi!

You get this message because you are an admin on a Wikimedia wiki.

When someone edits a Wikimedia wiki without being logged in today, we show their IP address. As you may already know, we will not be able to do this in the future. This is a decision by the Wikimedia Foundation Legal department, because norms and regulations for privacy online have changed.

Instead of the IP we will show a masked identity. You as an admin will still be able to access the IP. There will also be a new user right for those who need to see the full IPs of unregistered users to fight vandalism, harassment and spam without being admins. Patrollers will also see part of the IP even without this user right. We are also working on better tools to help.

If you have not seen it before, you can read more on Meta. If you want to make sure you don’t miss technical changes on the Wikimedia wikis, you can subscribe to the weekly technical newsletter.

We have two suggested ways this identity could work. We would appreciate your feedback on which way you think would work best for you and your wiki, now and in the future. You can let us know on the talk page. You can write in your language. The suggestions were posted in October and we will decide after 17 January.

Thank you. /Johan (WMF)

18:17, 4 January 2022 (UTC) MediaWiki message delivery (talk) 18:17, 4 January 2022 (UTC)Reply