User talk:Wbm1058/Generate automatic summary /* blah */ when I manually add a section heading when editing

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Subpage of User talk:Wbm1058#Generate automatic summary /* blah */ when I manually add a section heading when editing. — Preceding undated comment added 16:22, 25 November 2020 (UTC)

Headings of Requested move[edit]

Why including headings as part of a template? There is already a subject/headline box. --George Ho (talk) 08:55, 12 December 2014 (UTC)[reply]

For editor convenience. See the discussion Here. This ensures that section headers are unique, i.e., so there will not be two sections on the same talk page both titled "Requested move". The {{Requested move}} documentation explains how customized section headers can still be used, see Template:Requested move § Custom header. Wbm1058 (talk) 13:23, 12 December 2014 (UTC)[reply]
I've found (err, a beta version of my bot has found) three open RM's which are malformed, e.g., this one. The bot is not picking up the section links for these. It doesn't work when there are comments inserted between the section header and the RM template. Having the template write the section header, at least initially ensures that doesn't happen. Wbm1058 (talk) 18:48, 12 December 2014 (UTC)[reply]
  • I just noticed this comment, which was posted a few days later, which I overlooked before: "It's nice that there is a default header with such precision, but if the editor proposes the change using the "new section" button and has to leave the section header blank, it's unfortunate that we end up having a new requested move section with no edit summary; there's no quick way for editors with the page on their watchlists to figure out that a move was requested. Would there be a way to check for the bot to check for new move requests that have no edit summaries and add some sort of dummy edit to notify editors that a move discussion is what was added to the page?" I'm chewing on what the best way to do this is. The contested technical requests set up by {{RMassist}} automatically populate the edit summary, but that only works when clicking on a link. Sure would be nice if there was a way to populate edit summaries by just using a template. But a followup bot edit is a good idea too. – Wbm1058 (talk) 11:49, 1 May 2015 (UTC)[reply]
See also: Related discussion HERE. – Wbm1058 (talk) 04:23, 21 November 2015 (UTC)[reply]
...and below. Wbm1058 (talk) 04:41, 21 November 2015 (UTC)[reply]

New interface for Special:MovePage[edit]

We seem to have lost the permalinks when moves are performed at WP:RMTR. When you hit the 'move' button a new-looking interface is presented, though the questions are familiar. Perhaps MediaWiki has just been updated? If so there ought to be an announcement somewhere. There is no recent change in RMAssist. And the MovePage command is populating the old and new title fields correctly, just not the reason field. That's where the permalink would normally be entered. EdJohnston (talk) 19:32, 24 September 2015 (UTC)[reply]

It's in the "latest tech news":
  • The page move tool has been switched over to the new standard look for forms. [1]
Jenks24 has already filed a report: "you lose whatever you've previously written in the "reason" field. This didn't use to happen."
Sigh. Can these guys change anything without breaking stuff? I see the two-notifications is back, and the "Your messages" notification still says I have one unread message, even though I've obviously already read your message. They should back off this breaking change until they address this problem. Wbm1058 (talk) 20:04, 24 September 2015 (UTC)[reply]
If you can add to my report there, please do. I'm not as tech-savvy as you, so you might be able to better explain what broke (and perhaps why?). I largely agree with your other comments here as well, though I've tried to be less openly critical on places like VPT as of late because the whole developer system is so opaque – I never know if the person(s) I'm criticising is some poor volunteer doing their best with limited resources, a peon in the WMF's ever-expanding bureaucracy, or the head tech honcho. It's so hard to know who comments or complaints should be addressed to and where.
On a related note, I've tried to get somewhat involved with phabricator lately and have no idea what I'm doing. Check out this simple request (or I thought it was simple) that I made over a month ago. I have no idea if there is some sort of system for someone to ever get around to it, and if there is a system I have no idea where my request is in the queue. I'm beginning to think I should have just made the hack here on en as I'd first thought and bugger the other projects. Jenks24 (talk) 20:27, 24 September 2015 (UTC)
I'll try to take a closer look at that later. I never did completely figure out bugzilla, and haven't used phabricator much yet either. Just looked at the new "move form". So, it seems to be just a cosmetic change? Where's the improved functionality? Why are they wasting time on something that's not broken? I don't really see the point. Wbm1058 (talk) 21:05, 24 September 2015 (UTC)
Hello, Wbm1058 and Jenks24. I'm glad Jenks added a note to the Phabricator report. It's possible there is more that is broken. A person could take the expansion of the RMAssist template, click it, and show that a move request form opens up with the reason information missing. I almost had a working test case and could complete it if it is likely to be helpful. In terms of who to talk to, the author of this Gerrit about MovePage: https://gerrit.wikimedia.org/r/#/c/185591/ is User:Matma Rex, who we had discussions with in early 2014. Someone could probably write to him directly, since he gives his email on his user page. EdJohnston (talk) 21:13, 24 September 2015 (UTC)
Ah, I see, the guy who gave us permalinks to diffs, that is a very useful feature which I use all the time. Wbm1058 (talk) 21:40, 24 September 2015 (UTC)
@EdJohnston, Wbm1058, and Jenks24: Sorry folks, I indeed broke that with this patch, and I've only noticed the comments on the original task today. It's now being handled at phab:T113718, we'll try to get the fix deployed today (if possible; it's Friday and Friday deployments are generally frowned upon) or on Monday. Please watch that task for updates. (It also appeared on VPT, not sure if you've seen: Wikipedia:Village_pump_(technical)#File_renaming.) Matma Rex talk 12:58, 25 September 2015 (UTC)[reply]

Follow-up on the related note[edit]

@Jenks24: Sorry, I forgot about this, so now just getting back to take a look. Turns out your phab:T109323 of August 17 was redundant to the earlier phab:T85650 (Special:MergeHistory success message should include redirect=no on the previous title, January 1, 2015). Here are the code changes which were committed Sep 29 2015 (5 days after you asked me about this), description of the solution is: "Removes mergehistory-success message and introduce mergehistory-done so that fullurl doesn't have to be added to each translation message." Does that fix it as you wanted? I need to get back to doing some hist-merges myself to check this out; I guess I'm just too used to 'following redirects then clicking again to see the source' for this to have bothered me much. Nice to see how they hardcode default messages which individual wikis can override by editing their local MediaWiki message. I hadn't really seen how that works before. So, yeah, my experience is that once you enter a bugphabzillerarata it just sits forever [like an {{indef}}] until someday someone decides it's something they want to work on, and then one day, out of the blue, you hear that someone fixed it and it went live! Yeah! But, per Wikipedia talk:Wikipedia Signpost/2015-11-04/Op-ed, it seems they are now getting more serious about "surfacing and prioritizing technical needs from the community". So maybe there's hope for better follow-up in the future. BTW, I entered a request HERE. Which would help address the issue discussed ABOVE. Hoping that nobody trouts me for canvassing ;) Matma Rex, I see that you are on the Editing team. Any chance you might be able to take a break from your Multimedia work and do some "(purely maintenance)" work on the basic MediaWiki default wikitext editor inside EditPage.php? It seems to be dealing with section editing and section edit summaries in this part of the code. I was told that this is crufty code that most people would be reluctant to mess with but here I see that it's still being modified fairly often. – Wbm1058 (talk) 20:05, 21 November 2015 (UTC)[reply]

Thanks for the ping. Yes, I have seen the change (and used it since). It works just as I'd wanted so a big thanks to Glaisher who I think was the one who made the fix. (Incidentally, the little thumbs up at phab:T85650 is from me, I was hoping it worked similarly to the thanks notification feature here but have no idea if it does.) And I do think the WMF has made a serious effort try and increase engagement between "regular" editors and the developers, so perhaps I should stop whinging about them so much. Still, it would be nice if there was some sort of indication for when a bug you file is likely to be fixed, if any developers have looked at it and decided not to pursue it for whatever reason (not important, too hard, not something they're interested in), and whether the WMF-employed devs are ever planning on having a go at it – if it really is just waiting for a nice volunteer developer to see your bug and decide it's something they want fixed too, then I probably need to start making friends with some devs so I can annoy them about fixing the bugs I care about. And no worries about canvassing . I've already seen the community wishlist survey and have commented on one or two. I thought about adding a couple of proposals myself, but decided they were probably too niche. But while we're pinging devs, I'll plug them here in the hope that might precipitate some movement. phab:T12814 (note my clumsy attempts to poke someone into working on it there) would make my life a lot easier. The amount of times I have to open another tab to check whether a talk page redirect has more than one edit in its history and if so delete it so the move goes through cleanly (or forget and then have to move the talk page as a separate move) is a little ridiculous. The other one I'd love to see fixed is phab:T20104 (see User talk:Graham87/Archive 33#Unable to delete certain revision for background), but considering there has been no movement since 2010 and changing the whole schema for deleted edits sounds difficult even to a layman like me, I'm not holding my breath on it. Jenks24 (talk) 10:09, 22 November 2015 (UTC)[reply]
"Contributed patches are very welcome and the best way to get this task closer to resolution." Yea, I've found that page before. Seems like a fairly steep learning curve, but one I'm probably capable of climbing if I dedicate my life to it. Continuing ed classes in PHP and regex, if available at my local university, would be helpful. So far, I'm just self-taught in those and muddling through by learning enough to support my bots. I wonder, if I climbed that hill, would the Foundation buy me a cup of coffee? It bugs me that, while they continue to rake in growing piles of cash off volunteer labor, they can't find resources to motivate developers to jump-start tasks like this. No shortage of cash to pay for round-the-world travel though. OK, /soapbox. I hear what you're saying about stopping whinging about them so much. Pinging @Ryan Kaldari (WMF): if he cares to comment. Wbm1058 (talk) 17:32, 22 November 2015 (UTC)[reply]
@Wbm1058: I agree that the WMF has neglected the needs of the core community for a long time. Hopefully that is slowly changing due to leadership changes and the completion of large high-priority projects like Echo, Visual Editor, Scribunto, etc. The challenge is that there is a very long tail of technical needs and it's hard to figure out how to prioritize them. If you have a need that you don't think is popular enough for something like the Wishlist Survey, my advice is to write a really detailed Phabricator ticket and if you don't get any traction, try to find out which developers work in that area of the code and ping them on the ticket (using the blame feature in http://git.wikimedia.org/ is useful for figuring out which developers work on which code). And if you're able to write any code yourself, that definitely helps. I know the process can be slow and frustrating, but we're all trying to do our part. Cheers. Ryan Kaldari (WMF) (talk) 22:43, 23 November 2015 (UTC)[reply]
Thanks. I this item is up to three endorsements in your survey now. I also merged in a task where someone reported the same issue back in July 2005 – so the "bug" has celebrated its tenth birthday! Wbm1058 (talk) 23:03, 23 November 2015 (UTC)[reply]
wikt:whinge. I understood the meaning from context, but that's not generally part of American English. Wbm1058 (talk) 17:57, 22 November 2015 (UTC)[reply]
Hah, and here I thought whinging was universal. Jenks24 (talk) 09:45, 23 November 2015 (UTC)[reply]
  • "So, yeah, my experience is that once you enter a bugphabzillerarata it just sits forever […] and then one day, out of the blue, you hear that someone fixed it and it went live!" Every month there is about 3500 tasks filed and 2500 closed [2]. It's harder to tell how many of the 2500 and the 3500 are the same tasks, but as of right now 945 of the tasks filed last month are already closed [3], so I guess you're looking at somewhere around 13 chance of your issue getting fixed within a month. Could be worse, could be better. (Some projects do better, for example I'm proud to report that we're closing more UploadWizard tasks than there are getting filed :) [4])
  • "I see that you are on the Editing team. Any chance you might be able to take a break from your Multimedia work and do some "(purely maintenance)" work on the basic MediaWiki default wikitext editor inside EditPage.php?" Mmmmmaybe. EditPage.php really is scary and liable to cause headaches, which may be fatal. But phab:T22307 seems straightforward enough to avoid prolonged exposure ;) One reason why I would be reluctant it is that it's impossible to write a fully correct regex that decides whether some piece of wikitext creates a new section (for example, try to do it with these edits: [5]), and then we'll have people filing umpteen bugs that it doesn't work in specific cases (like it's happening now with Echo mentions). Maybe we can make the parser give us this information – but then, the Parser class is another headache-inducing one…
  • @Jenks24: "Incidentally, the little thumbs up at phab:T85650 is from me, I was hoping it worked similarly to the thanks notification feature here but have no idea if it does." Indeed it does, and people get web notifications for it in Phabricator by default, although it's public who gave each token (your name appears when you hover your mouse over it). It's more like Facebook likes (the horror!).
  • @Jenks24: "Still, it would be nice if there was some sort of indication for when a bug you file is likely to be fixed" Some teams track tasks they're going to work on soon in "Up next" or "In progress" or similar columns on their team dashboard, which is usually a good indication, same when somebody assigns the task to themselves or triages it as high priority. If none of this happens,
  • @Jenks24: "phab:T12814 […] would make my life a lot easier." Hmm, looks easy enough. I'll look into it and see if there's a "catch" explaining why it was never fixed ;) "The other one I'd love to see fixed is phab:T20104" As you note, schema changes are a big deal when you're the size of Wikipedia, and the sole DBA has plenty of work as it is :(
  • "Continuing ed classes in PHP and regex, if available at my local university, would be helpful. […] I wonder, if I climbed that hill, would the Foundation buy me a cup of coffee?" "Individual Engagement Grants" are available, although they're usually for bigger tasks. If you do get back to college, Google Summer of Code might be an option; or if you're "diverse" enough, Outreachy (alas, they both also require you to come up with a larger self-contained project). Matma Rex talk 20:24, 22 November 2015 (UTC)[reply]
  • Also, I was not going to reply to this, but I'll take the bait. "No shortage of cash to pay for round-the-world travel though." I'm not sure if you mean the yearly "All Hands" event in San Francisco (which should really be called "All Employees", as contractors don't get to go :( ) or the European hackathon and Wikimania (most people only get to go to one, especially if either happens to be in a more exotic/expensive-to-travel-to location). I think the first is a great rare opportunity for remote employees (~50% of engineering people) to actually meet each other in the flesh and recognize as actual living humans (and think how much we save by not having to pay everyone the crazy SF rates :P), and the second is a nice perk which might be allowing the Foundation to keep SF people who could otherwise leave for one of the many tech companies around San Francisco with bigger budget than the Foundation. (You can find a lot of information about WMF salaries online, since it's required to disclose those for H-1B visa workers and some more through Form 990.) Matma Rex talk 20:58, 22 November 2015 (UTC)[reply]

Matma Rex, Thanks for your detailed reply.

  • Looking at the specific project, MediaWiki-Page-editing that my request is classified in, I see "All Time" 1,422 opened tasks and 66 closed tasks. Page-editing is perhaps the most end-user facing project of all that Wikimedia does, so perhaps this contributes to my distorted view of the overall accomplishment rate. Overall, I find the core editing experience to be high quality, so I have trouble wrapping my mind around the idea that there are over 1400 bugs. There aren't really that many things I know of that need fixing, unless Visual Editor is included in this bucket. So, on the relatively rare occasions I do identify a bug or sorely needed feature, I guess I have high expectations that it should be addressed, as from my view, there really aren't that many problems with core editing.
  • The errors with template or nowiki syntax inside section headers are there now, and this task shouldn't change that. I'd just ignore the issue, as editors don't do that often that I've seen. Maybe there's another phabricator for that one. The solution, I think is to either treat template and nowiki markup as plain text when it's inside section headers, or throw an error and refuse to save the edit. But that's something for another phab.
  • I see that many (most) universities don't teach PHP even though it's so widely used on the web. So, though I have a masters degree, I'm looking at the local community college. I think the tuition's a lot less there too. I see that I'd probably start with a 3-hour HTML course that also taught CSS. There's been times here that knowing CSS would have been helpful, and my last formal training in HTML was in the stone-age of the Internet. The HTML/CSS class is the prerequisite for both a "web database development" class that teaches MySQL and PHP, and a JavaScript course. Classes start in January. I'm thinking about it. Regarding something like Outreachy, I might only qualify under "age diversity". I learned how to program a Programma 101 in seventh grade, and in high school, an IBM 1620. I learned BASIC the same way Bill Gates did, on a Teletype connected by an acoustic coupler to a GE time-sharing system. Re: that scary class, yes the concept of classes is still new to me, I don't have much experience with object-oriented programming.
  • Sorry for throwing out the bait. To clarify, I don't have a problem with spending on travel, as long as it's not at the expense of support for the core of the projects. Wbm1058 (talk) 00:23, 23 November 2015 (UTC)[reply]

Matma Rex, thank you so much for your reply here, it's brilliant and the stats are quite interesting. I see that you've claimed phab:T12814 and are looking into it – again I'm very grateful. I feel a bit guilty, though, that it's only really happened by pinging you here. I would not feel comfortable just pinging devs for every little bug that I care about, but conversely I'm not sure if there are any "official" channels where I can ask for certain bugs to be looked at if it seems they have been waiting significantly longer than a month? Or is this how things are intended to operate at the moment, we should be reaching out to certain devs if we can think the bug in question is an area they are interested/experienced in? If there is someone else in the WMF who I should direct these questions to, I would be happy to move my questions to their talk page so that you and Wbm can keep discussing computing jargon that flies over my head . Thanks again, Jenks24 (talk) 09:45, 23 November 2015 (UTC)[reply]

  • Hmm, 1,422 open and 66 closed for MediaWiki-Page-editing is definitely not right. I think the burnup report doesn't consider bugs closed before the Bugzilla→Phabricator migration. If you search for the list of all open/closed tasks, you get 310 open and 1103 closed. I filed phab:T119376 about this issue.
  • I don't think Google Summer of Code has a maximum age limit. It seems that in 2014, there was a participant who was 57 years old [6] :)
  • @Jenks24: Indeed, there isn't any "official" way to do this :/ WMF engineering operates on quarterly goals and reviews (and why these two pages are on different wikis is beyond me). If you want to affect these, then you could probably send emails to some relevant mailing lists before the beginning of a quarter. Many staff recognize this as not exactly optimal, and there's a lot of work being done "under the table" that doesn't quite match the goals; asking people directly is fine. I don't really know how this system came to be, or who to question about it, but presumably someone higher up than me ;) The mw:Community Tech team and their community wishlist survey is an interesting change and I'm myself curious how it turns out. Matma Rex talk 12:12, 23 November 2015 (UTC)[reply]

New section test[edit]

What will the edit summary be? Wbm1058 (talk) 22:02, 17 November 2015 (UTC)[reply]

See m:2015 Community Wishlist Survey/Editing § Generate automatic summary /* blah */ when I manually add a section heading when editing
Your support for this enhancement / bug fix would be appreciated. Wbm1058 (talk) 16:55, 18 November 2015 (UTC)[reply]

@Matma Rex: I was so excited to see you post a fix for this, but now I'm disappointed to see no further movement on the code-review for two weeks. Is there a test wiki where this is installed where I can beat on it as an end-user checking various use cases to see if I can spot any issues? Anything I can do to help move this along the deployment pipeline? Thanks again for all your help. wbm1058 (talk) 16:32, 18 April 2016 (UTC)[reply]

Sorry, it's just a personal project for me. I need to work on it some more (see the TODO items at https://gerrit.wikimedia.org/r/#/c/281470/1) and I just didn't feel like it (I've already done all the interesting work and only the boring parts remained :( ). It's not available on any testing wiki.
If you want to try it out, you could try setting up a MediaWiki instance on your computer with a Vagrant virtual machine (mw:MediaWiki-Vagrant#Quick_start), this shouldn't require a lot of technical knowledge (beyond knowing the basics of command line interfaces). System requirements: 64-bit OS (Windows/Linux/Mac, all fine), processor with support for VT-x (almost anything that isn't ten years old should work) a couple gigabytes of disk space for the virtual machine, and a bunch of RAM (I'd say 4 GB or more should be okay, looks like the VM requires at least 1.5 GB). Ping me at #wikimedia-dev connect if you're interested and need help :D Matma Rex talk 19:21, 18 April 2016 (UTC)[reply]

New section to test German tool[edit]

This is just some random comment. Wbm1058 (talk) 03:22, 11 January 2016 (UTC)[reply]

I was testing de:User:Perhelion/sectionSummary.js (see w:de:Benutzer:Perhelion/sectionSummary), and while I think it's a good idea, I found its implementation still has kinks to be worked out. Wbm1058 (talk) 17:49, 17 January 2016 (UTC)[reply]