Fri, Feb 17
Thu, Feb 16
Wed, Feb 15
Hi, I might be able to help, if the task is just understanding where these are containers are coming from? Please could you point towards the existing example(s) that you found? (I couldn't see anything in the older task, but might've missed it)
Tue, Feb 14
+1 to "Editing help" being normal linked blue text.
1 emphatic request: Please make the main links use the normal Blue color, as per almost all standard links on our sites.
- Context: I first did a mouse-over of (more) because it was the only blue link (but then I saw it was just another local search). After I realized that "Irlanda" was the direct link, I tried clicking on ALL the bold black text (and icon), because I was suddenly unsure which parts were links, and which were just bold text...
Mon, Feb 13
Sun, Feb 12
I think we just need these actions, to resolve this task:
- Amir1, Huji, and EranRoz, to join the IRC channel.
- Discuss a regular meeting. (Not everyone is permanently on IRC, so I guess the mailing list will be our "coordinate with everyone" method. I've started a thread...)
Sat, Feb 11
Fri, Feb 10
Thu, Feb 9
- Admin email fwd'd to Huji.
- List settings changed to private archives, require "Confirm and approve" for new subscriptions, plus added description, and short subject line prefix ("TLSC").
- I'll mass-invite the rest of you.
(Sorry for the delay. Phab-mail backlog)
Wed, Feb 8
- Template code: Yes please, to divs instead of tables!
- Image-wrap/whitespace: When the template is displayed in the visual editor edit-notice box, I think it would be fine to make the text wrap around the icon.
- Image location: In the above circumstance, relocating the image to the top-right corner (for LTR) seems potentially reasonable.
- I assume relocating it to the top-left corner would cause some text line-wrap ugliness? Perhaps we could try out limiting the image height to a certain pixel limit, so that it only wraps after 2 lines or so?)
Fri, Feb 3
This is a very complex topic, that was last addressed as a whole (AFAIK) in ~2014.
IIUC (I am not a developer), the performance issue, is that if any large wiki (or many small wikis) request custom sizes, then
- (A) the thumbnail-generating machines will have to work harder (and might run into hardware limitations, and thus slow responses) - This is especially a problem for the busiest wikis, because if we change the default then it will take hundreds of hours to generate new thumbnails, yet they'll be needed instantaneously. The devs want to pre-emptively generate the desired sizes, en-masse, once we firmly decide on a size.
- (B) the thumbnail storage/caching requirements will rapidly increase (but not in a way that benefits all Wikimedia users). I.e. If XXwiki requests 260 and YYwiki requests 250 and ZZwiki requests 270, then the storage requirements will more than triple.
(Sorry for delay in replying.)
No, we don't need to grant new team-mates access to the archives. (We just search our personal mail-client archives when needed. Plus, new team members don't have reason (or time!) to dig through the month-by-month web-archives).
Thu, Feb 2
Mon, Jan 30
There's a larger list of options (not including the one above) at
I'd tentatively suggest merging this task into that section? Or vice-versa.
I've clarified the description with some explanatory links and notes, and changed to Lowest priority because it hasn't been mentioned (afaik) in the last 2 years. I'm just clarifying whilst I have it open (was looking for something else).
Thu, Jan 26
Wed, Jan 25
I've edited the description, hopefully making it a bit clearer, plus linking to older/related tasks.
Possibly! Quick clarification questions:
- Where/who - IIUC, that page is intended to be an announcement, and needs to summarize [various changes], to a broad range of user demographics. Is that correct? If so, where is it going apart from the mailing lists? E.g. will it replace the message at the top of https://stats.wikimedia.org/EN/Sitemap.htm etc?
- When - What is the Final/Target Deadline for getting this info broadcast? (I.e. "Today/A week from now/This quarter"?)
- What/how - Time-needed estimate? (1 hour? 4 hours? more?) -- For context: Is this request just to sanity-check/proofread the info in that one page, verifying that it makes sense to a relative outsider, and that relevant links are included for "more info"? Or, are there other pages that need to be analyzed in conjunction? (I can help relatively soon (maybe tomorrow) with this single page. But if I'd need to read through the /Future_per_report page and learn all about Data_Lake (and etc) then I couldn't help for at least a week or two and might suggest pinging a different CL if he's free.)
Thanks! (Also: Feel free to update the description instead of replying directly, if the task is bigger than I guessed. :)
- Email: I think just a private mailing list, might be sufficient to start with?
I've started a basic task at T156218: Create mailing list for Tool-Labs-standards-committee
We just need to agree on a name (!!). Either firstname.lastname@example.org or email@example.com ? (I have no preference, auto-complete knows all!)
Plus someone else needs to volunteer to be the backup spam-recipient/list-admin.
@RobH We'd be happy with just a simple new list, and transfer of settings. Thanks for the clarity!
- New list at tc [@] lists.wikimedia.org using the current settings+members+admin of cep [@] lists.wikimedia.org
- (optional, bonus) Ideally, anything sent to the old list address would auto-forward to the new address?
Jan 21 2017
Jan 20 2017
Jan 19 2017
Jan 18 2017
Tentative for this quarter, depending on dev progress.
Jan 13 2017
Jan 9 2017
Having the coffee/water/snacks in the same room as a session, meaning everyone getting drinks had to be asked to leave (or be silent).
Jan 8 2017
Jan 6 2017
Potential question for discussion (or moving to somewhere more appropriate!) -
- Where should volunteers go to get help, if they are having difficulties with Quarry, either due to
- (a) not knowing where to even begin writing/adapting a query,
- (b) their own inefficiently written queries (which just need minor tweaking), or
- (c) due to unavoidable timeouts even with efficient queries (which would need to be run from a terminal)?
Jan 5 2017
(re-)Read and Signed.
Jan 4 2017
Jan 3 2017
It might be easier and cleaner (avoiding the need for code complexity) to just rewrite the label as "Log" or "Log entry" ? Or something similar?
I've moved the page. Thanks for passing the request along.
Jan 2 2017
@Peachey88 Ah, I should've prefaced my comment with "This is a datadump, because I too am not sure where is best to discuss it all, but I think it is more complicated than it might appear".
I'm very hesitant about changing it, for a few reasons. For all these reasons, I believe we would need to have a detailed discussion and plan, for exactly where/when the "display name" would be displayed, in both Wikimedia and non-Wikimedia wikis, before anything is changed. Briefly:
- Multiple names per user - One old argument against having an alternate display name, is that it makes it harder for other editors, or admins/etc, to rapidly understand who they are communicating/working with, or trying to block. E.g. if a page-history says edits were made by "Alice Smith", but there is no "User:Alice_Smith", then everything is more complicated.
- (This is similar to the issue where: a person I work with has at least 5 completely different identifiers: given name, surname, username, IRC nickname, email address.)
- Potential semi-impersonation issue - there was an old issue (per), possibly fixed (?), where, E.g. I, as "User:Quiddity", could set my "real name" preference to "Bob Smith", even if there was already a "User:Bob_Smith" registered on that wiki. This would normally be prevented in usernames, via https://www.mediawiki.org/wiki/Extension:AntiSpoof
- Non-uniqueness - Related to the above, a benefit of using a single name is that everyone is uniquely identifiable, and fairly easy to clearly refer to. The concern is that we would have hundreds of editors who all have the display name of "John Smith". (and other common names).
- I recall these 3 ^ being given as reasons for opposition to complex signatures. It was suggested that signatures should only allow formatting-style-changes, and not content-changes. -- Related to this 'real/display name' idea (as primarily needed by editors working in 2 or more languages with different character sets), one solution would be to show the 'display name' and the 'username' together. E.g. signatures could by default be "-- Username (Display Name) timestamp".
- Expectations/Consistency - If we call it "display name", then some editors will reasonably expect it to be displayed everywhere instead of their username. (cf. requests by teachers who are frustrated by studentID#s appearing everywhere)
- Non-Wikimedia wikis - I'd like to learn how other non-Wikimedia wikis [might/will] be affected by this change. (Unless it could be done so that it only affects Wikimedia wikis?)
Dec 29 2016
Dec 23 2016
- #wmhack is the standard channel for the Hackathons (standalone and Wikimania). That's a good option. -- (54 people currently idling in there)
- Last year's devsummit used #wikimedia-tech which is also a good option. (per) -- (202 people currently idling and sometimes talking, in there)
How many channels do we need, though? We might need 2, but let's avoid more than that, and let's avoid setting up any new channels.
I'd tentatively suggest:
- #wmhack for social chatter ("who has an adaptor?" and "has anyone seen Alice?" type discussion)
- #wmhack also used for Room 1 discussions.
- #wikimedia-tech used for Room 2 discussions.
(or something along those lines, and assuming that we're streaming both Rooms 1 & 2.)
Dec 22 2016
Dec 21 2016
Dec 19 2016
Dec 18 2016
Is this a duplicate of T687: Convert Bugzilla's "Bug NNNNN" links to "TNNNNN" links in Phabricator ? (It seems to be, but perhaps I'm missing something?)
Dec 15 2016
I strongly urge
- Everything on one page (instead of split into 3)
- This enables (A) easier watchlisting, (B) better usability (and less page-loading) for checking/searching for a session (e.g. if I don't remember what day it is happening), (C) easier editing if we want to move something from one day to another.
- the use of basic tables with minimal styling, for ease of editing by everyone
- I assume unconference sessions will be added as a 3rd column, and thus participants will need to be able to edit the page many times during the days. The easier it is to edit (especially on mobile), the greater chance there is that edits will be made.
- This revision was readable on mobile (especially if I rotate 90degrees, but even without), and clearly showed concurrent sessions, and can easily have the extra meta-info added (and tweaked during the event): https://m.mediawiki.org/w/index.php?title=Wikimedia_Developer_Summit/2017/Program&oldid=2312539&mobileaction=toggle_view_mobile#Schedule
Dec 13 2016
Dec 12 2016
I've replied (hopefully with correct details) at https://meta.wikimedia.org/wiki/Talk:User_language#Issue_with_ase - If that's the only thing that needs to be done to fix this (and I think it is), please close this task. :-)
(Note, it normally takes at least 24 hours for fixes at translatewiki to get pushed to production. However there's currently a technical problem with the cron job, so there will be no updates till that's fixed)
Dec 10 2016
Note: Some frustration was expressed regarding this change, at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#More_facebookery
I do agree that the layout seems to have degraded in this particular change, changing from a ~60px tall box, to a ~270px tall box (per screenshots in task description), without any benefit.