Greetings. My name is Nick. I live and work in the inner west of Sydney, Australia. I write, sell, and support software for a living.
By the way, the 'J' in my username is for the first letter of my surname, and there is no particular reason for the J being lowercase rather than uppercase.
Lately I have been occasionally checking-in a few small things in the MediaWiki software that'd I'd like to be changed. Prior to this, I was doing fuzz testing of MediaWiki and reporting bugs found, and then the other developers came up with the very cunning plan of giving me commit access ... as a result of this, I now feel a bit slack if I only ever report bugs and don't occasionally fix something.
The Can We Link It tool for suggesting links. This supersedes the Link Suggester and LinkBot. As a related project of suggesting links, the code for this needs to examine the wiki syntax of a page. It informs about pages that have malformed wiki syntax, such as malformed brackets. The project to get these problems fixed grew and evolved to become the Wiki Syntax Project, although the Can We Link It tool now also checks syntax too.
As a related project of suggesting links, I previously ran a project for automatically suggesting new useful redirects and disambiguation pages, from the data that we have already got in the Wikipedia. I'm not quite sure where this fits in the bigger picture at the moment, so I may come back to this later on.
Suburbs of Sydney, as part of the Sydney Suburbs WikiProject. Started with Summer Hill (using a deep but narrow approach), and then later moved to helping add missing stubs (using a shallow but broad approach), so that all Sydney suburbs should (hopefully) now have at least a stub at the right place, with mapping info.
My girlfriend and I have a maine coon cat. They're an interesting breed - they're smart for one thing, and they're naughty too (e.g. whilst fast asleep, try being jumped on at 4 AM from a height of 8 feet by a 7 kilo cat - you wake up pretty quick).
These things are just ideas that interest me at the moment - nothing has been done on them yet - rather they're things I may do in the future.
Suggesting redirects based on bolded text (suggestion from Susvolans). Would work something like this:
For each bit of bolded text in the first paragraph:
If there is not already an article or redirect of the same name as the bolded text:
Suggest making a redirect from the bolded text name pointing to this article.
These suggestions would then be listed in a format something like the redirect suggestions, for human review. If these redirects get added, then the link suggester will automatically use those redirects to suggest possible links.
One thing I'd like to do (and I must strongly emphasise that this is just an idea at this stage, at the end of very long list of things to!) is this: HTML validate the entire English Wikipedia (and produce a list of all the errors, same as for the Wiki things). This should get every mismatched div tag, every stuffed HTML table, every bad HTML entity - the whole enchilada across the whole Wikipedia. I see this (for the HTML side) + the what the Wiki Syntax does already (for the wiki side) as being the ultimate combination for these types of problems.
non-existent-redirect-message template. Example usage: {{User:Nickj/non-existent-redirect-message|topic=German Infantry Divisions|list-link=Wikipedia:WikiProject Wiki Syntax/non-existent-redirect-000.txt#German divisions}}
I like the Wikipedia very much, but these are some things that in my opinion are wrong with the Wikipedia:
The process for deleting content is political, slow, and is the single most frustrating thing. Adding things is easy. Changing things (that are not protected) is easy. Deleting things is ridiculously painful. There has got to be a better way. Bring on easy deletion and undeletion of content by users.
Everybody wants to vote, but precious few people fix problems. Voting on something is easy. Acting to fix a problem is a lot harder. It would improve the Wikipedia if people voted less, but did more.
Discussions: To have a discussion requires listening to the response! Too often people walk into a topic, leave their opinion, and vanish, to never come back to respond to questions / comments about what they have added. If you don't intend on responding, then don't leave the message in the first place. Wikipedia is not a soapbox.
Consensus is great in theory, but useless in practise. Someone changing their position rarely happens. More than 3 people can't even agree on what video to rent, so how can 15 people all agree on what to do about a controversial topic? They can't, which leads to majority rules. Which would be fine, if we said "majority rules" was the decision-making process, instead of the pushing the daydream of "consensus".
Perma-protection of articles and templates. Fine when used temporarily, but perma-protecton prevents change. It might seem a good idea at first for vandalization targets, but protection prevents even constructive change.
Easy rollback should be possible for established users cleaning up clear vanadalism from anons or blocked users. [1][2]
Personal preference rather than a problem, but I'd quite like to see 30x HTTP redirects in place for URLs that omit the "wiki/" bit (e.g. http://en.wikipedia.org/Tokyo → http://en.wikipedia.org/wiki/Tokyo ), instead of the client-side meta refresh that we currently have. [3]
I think that searching engine indexing of the mailing list archives should be re-enabled. [4]
I agree to multi-license all my contributions, with the exception of my user pages, as described below:
Multi-licensed with the Creative Commons Attribution Share-Alike License versions 1.0 and 2.0
I agree to multi-license my text contributions, unless otherwise stated, under Wikipedia's copyright terms and the Creative Commons Attribution Share-Alike license version 1.0 and version 2.0. Please be aware that other contributors might not do the same, so if you want to use my contributions under the Creative Commons terms, please check the CC dual-license and Multi-licensing guides.