Jump to content

User:TheProgrammingGuy

From Wikipedia, the free encyclopedia

Edits

[edit]

Wikipedia is awesome. Wikipedia has so much knowledge, it's insane. But I've only made edits since May of '06. I hadn't created this account for the first couple, but other than that, I've used this account.

To date, I've done a bit of fixing on the L33t programming language page. Unfortunately, not long after it was taken down. Recently, however, it has started being rebuilt, so I may help work on it at some point later.

I've also started some work on the PlayStation versions of RPG Maker (RPG Maker 1, 2, and 3). I just started, but hope to get those articles looking better.

P.S. I think I used too many userboxes. Maybe.

Userbox Wars

[edit]

You may have noticed that I used a lot of userboxes. I like them. They let people know what I like. And I believe userboxes to be harmless in the Template namespace. Clean up the template namespace? Please. What makes it so unclean? What constitutes clean? And no, I don't like the idea of substing every userbox. Not really because I would have a mess of code on my page, that's not an issue, I can deal (I write code for a living, I'm used to text). But doing this would go against part of the argument for substing.

An argument for deleting the actual templates and substing all userboxes is to (hopefully) lessen faction vote-stacking. Anyone who is currently part of a faction that stacks votes will continue to do so. They already know their contacts, and moving the userbox to userspace isn't going to stop them. This may, however, help deter new members to this type of faction. However, it will also deter new members to EVERY group, however helpful to the wiki they may be. Also, as new members do happen to join the vote-stacking factions (because they will), it will be much harder to track them. With no what links here capability, new members will be MUCH harder to identify. So, although the rate of growth of these factions will slow, I believe the rate of catching them in the act will go down as much if not more.

Also, the argument that moving them to userspace will allow people to edit it to their tastes is a moot point. If I wanted to change any of the userboxes on my page, I most certainly could go and subst it right now and change it. But I don't. I'm fine with the default ones. And being a programmer, I'm all for re-useability, and against duplication. I guess that would be my biggest bias. Because I work with databases on a daily basis, from the looks of the way WikiMedia is set up, I really can't see grabbing template code from a different source that much more of a strain on the server. Hell, as I was creating this, I continuously hit preview, and the page loading within a second to a second and a half. The database speed shouldn't concern you. What should concern you more is the transfer rate of the pages. That's the slow part. And that isn't going to change whether the userboxes are in userspace or not.

On the Mackensen Proposal

[edit]

Alright, so the Mackensen Proposal seems to be the big topic right now. This definitely does seem to be a good compromise, if you agree that there is a compromise to be had. Again, I really don't feel there is a problem, but I'm not against this proposal either. I've read many of the arguments, and they go both ways. But as long as the code for the userboxes is still available and in a central place (and organized), I really don't see a problem with going ahead with substing them. As for including categories in the default code, I'd like it to either be in there, or to be suggested next to the code. I don't want the categories to be destroyed. Again, you lose your grouping, and then that subject comes up for deletion debate.

As for exclusions... I'm leaning both ways. If your going to leave anything in the template space, I believe it should be babel, WikiProject, or skills/knowledge you can contribute to Wikipedia. I would think items like these very rarely are changed from the defaults. However, what is a skill/knowledge can be highly debatable. For instance, the head asplode userbox I included on my page could just be there for fun. But what if I included it to indicate that I have more than just a basic knowledge of Homestarrunner? Highly debatable. So, the skills/knowledge ones are out. The WikiProject ones I believe could stay, as that would let people easily find what they like. Those should never give any problems. And the Babel ones can stay too. No harm in those, and they let people know what language skills someone knows. But only the real language ones, and I technically wouldn't include programming languages either, as those are skills. So, either have WikiProject and Babel, Babel alone, or none at all.

The German Solution

[edit]

Well, here's a new idea, and one that I'm going to start implementing. I may look around to see if anyone has already put these up, but you know what? I don't really care. Everyone against userboxes in template space will just have to live with multiple versions of these things floating around. I'm fine with hosting them under the user accounts (especially since it's not costing me anything), but I'm vehemently against the idea of repetition. If someone substed a userbox on their page so they could change it, that's fine. It's no longer repetition if the content isn't the same. But to have forty people hosting {{User:UBX/Footballer}} because we can't have a centralized place for such a commonly used item bugs the crap out of me. But you know what? I don't care any more. Oh, and babel boxes shouldn't stay in template space, either. This is the ENGLISH wikipedia, other languages are superfluous; they should be handled however skill/areas of knowledge are handled. So really, the only special userboxes should be the wikiproject ones; THEY directly help the project.

My Userbox Archive

[edit]

Alright, I've gone ahead and started my userbox archive. I don't have the actual userboxes there yet, but that will be taking place soon. I'll slowly add them as I have time, and once they're all there, I'll update my pages to show this.