Hello to you too! :) Not really monitoring this, but when I saw it was you I had to come say hi!

Here's the original task where you can see @Yaron_Koren authored the proposal: T90238

@FilipGCI, I don't think that's what happens. The %20 kind of escaping is for use in URLs (such as php's urlencode), but this is escaping for HTML (< gets converted to &lt; and other things like that). Take a look at https://www.mediawiki.org/wiki/Manual:Messages_API#Output_modes_and_escaping.

@Legoktm, @Aklapper: Could you please resolve the conflict between this task and T152852? @FilipGCI says that the GCI task was claimed by them (https://gerrit.wikimedia.org/r/#/c/326282/). I haven't registered as a GCI mentor, so I don't know what's happening there.

@Robotnikman, hmm, weird. Can you check the browser console and let me know if you see any errors there? Javascript or otherwise?

@Robotnikman, that's rather surprising, because SmiteSpam was built and tested on a wiki using the Vector skin. However, it hasn't been tested in some time and something big may have changed. Can you give me further details, such as your MediaWiki version and anything that appears in the webserver's error log?

In T138304#2410965, @jayvdb wrote:

@polybuildr , I wont be debating the decision in public, as that is messy for all concerned, can't alter the outcome at this stage, and is contrary to the GSOC rules.
...
If you still have concerns after that, please discuss them privately...

Just remembered something from my experience last year, and I thought it would be relevant to share. From the IRC office hours before the start of GSoC and Outreachy last year:

Hi, I was a GSoC student last summer, and while I haven't mentored a student for GSoC, I did do a little mentoring for the previous Google Code In. Having had a great experience working with the Wikimedia community, I introduced @darthbhyrava to it.

@Anomie raised an issue in the Gerrit patch:

Should be fixed now as long as the version you're using is master.

Let's move the patch's discussion to Gerrit. I've uploaded a new patch - should fix this.

@Yaron_Koren, could you please check that the patch submitted works for you? After that, I'll merge. :)

That's odd. Will look into this and fix ASAP. Thanks for reporting!

We weren't able to syntax-highlight the code blocks on GitHub, but T128705: MediaWiki-Codesniffer README looks broken in Diffusion is interfering with that. This task looks resolved to me. @Legoktm, @bd808?

@Legoktm, @Addshore maybe this can be a microtask for T89682: Improving static analysis tools for MediaWiki?

In T127291#2079263, @Qgil wrote:

T91626: Technology to transclude git content into wiki pages was in the Featured column but in fact it had no mentors assigned in this round. I moved it to Missing mentors. It would be useful if someone could check that the other Featured tasks do have mentors ready, otherwise we are misleading candidates.

This task needs a few updates. PHPCS is now voting in several repositories (including core, iirc).

Sorry, while phpcs.xml works for individual repositories, we should probably be changing this in ruleset.xml using <exclude-pattern> I think.

I'm guessing we just need to add it to the ignored patterns in phpcs.xml?

I've also opened an issue upstream: https://github.com/squizlabs/PHP_CodeSniffer/issues/851

I do intend to, yes. Would you prefer it if I attempted to get it merged upstream and then just bump the version here?

Submitted a patch - it's an edited version of Squiz.WhiteSpace.SuperfluousWhitespace.

If I remeber correctly there exists a sniff for this, but I have not the name at the moment.

Thanks a lot @Qgil, for making this happen! :)

What is this?

It's been a month now, are there any updates? I'm sorry for asking so frequently, but I was really looking forward to interning at the WMF this summer.

Great work, @Sanjay311999.

This task is rather vague and it's probably a good idea to not propose this for GCI.

As per the discussion at T103800, since T467: RfC: Extension management with Composer was declined, the easiest way is to not autoload anything via composer.

@Aklapper, done. I hope that's satisfactory?

I'd like to propose and mentor this task for Google-Code-In-2015.

I'm going to propose and mentor this task for Google-Code-In-2015.

I'm going to propose and mentor this task for Google-Code-In-2015.

Sorry for the ping, but have there been any updates from WMF HR and Engineering?

That's a big oops.

In T116348#1747276, @Legoktm wrote:

That doesn't handle cases where we change the phpcs version requirement.

Any updates on this?

@Paladox, I'm not sure I understood the issue correctly. Is this to do with the fact that there are certain global variables without a wg prefix that codesniffer should not complain about?

Any updates on this?

Oh, that's great! Looking forward to good news on Wednesday, then.

@Qgil, any luck finding the actual owner?

In T102614#1705435, @Amire80 wrote:

Oh you're welcome, it's just shortening some lines ;)

@Amire80, you are AWESOME! :D

Is the only issue it being a verb? If so, we could go with "View previous versions", couldn't we?

Doing jsonlint using Grunt is a little weird, actually. The only JSON file that I can see in the repo is the package.json file. In order to use npm test, which will then get Grunt to lint the package.json file, the package.json file has to be valid in the first place. :P

The project was already using js-yaml as a dependency, so I gave this a shot by putting in a js-yaml config.yaml as the npm test script.

If that's what you're looking for, js-yaml is a very easy-to-use node module. Running js-yaml file.yaml prints out the JSON for the YAML in the file and the return status code of js-yaml tells us whether there was an error or not. Errors get logged to console too, of course.

You're looking for some configuration of npm modules such that when you run npm test, the YAML files get linted?

I tested this by updating CodeSniffer, and the issue was gone. Generic.WhiteSpace.DisallowSpaceIndent.SpacesUsed's code has changed and no longer checks for T_CONSTANT_ENCAPSED_STRING, so the issue no longer occurs. The CodeSniffer dependency was updated in rMCSN9a1a1acc5e8c: Update squizlabs/php_codesniffer to 2.3.4, but we still have to cut a new version ( T113516: Release version 0.4.0 of mediawiki/tools/codesniffer ). Once that is done, we can update core's version of mediawiki-codesniffer and we should be good to go.

@Legoktm and I spoke about this on IRC a while back - we do need to update to v0.4.0 also because of 62bddfe5ed8b2 and 0735677425.

Closing as invalid since we're unable to reproduce it. Feel free to re-open if it occurs again!