StrategyWiki talk:Community Portal

This talk page is for discussion of general community issues. To start a new thread, insert a new subheading above the rest. Resolved threads removed one day thereafter. You can find them in the history.

Discussion archives:

• Issue 1 - Early SW issues.
• Issue 2 - Wikibooks, Google Adsense
• Issue 3 - Discussions from Feb/Mar. Read if you're new! Good stuff!

Spoilers?

How far are we going to go to protect people from spoilers? I'm asking because of the confusing vagueness that's been injected into the Resident Evil 4 Chapter 2-1 boss fight - it reads badly, in my opinion, to be that deliberately vague to protect someone from discovering something they've already encountered in-game.
As I mentioned on that article's Talk page, I think that when you're reading a walkthrough it's reasonable to expect some of the events to be given away - that's part of the reason you're reading it after all. Otherwise, we might as well totally remove every in-game event from context with a bullet-point list of "go here; rotate this; go here; shoot" and so forth, to prevent anyone from learning anything about the plot before they play it.
The reason we've resorted to multi-page guides, apart from the better formatting and loading times it offers, is that people can read only the bit the're interested in, without going too far ahead in the plot. Why should we sanitize the actual walkthrough itself beyond that division? --aniki21 08:07, 24 January 2006 (PST)

I'm a bit confused, as I haven't played this game before. Does it reveal information that would be a spoiler? As you can see in the Zelda: Ocarina of Time guide that I'm working on, there are quite a few "spoilers"--see this for an example. I believe if someone reads through the guide with as they would a strategy guide that they buy in stores, that they won't have a problem with spoilers. Sure, our guides will reveal things, but only after they have occurred in the game. Sometimes it is not required for us to do so, but often it is necessary. That's my opinion, anyway. We can always judge on a per-game basis. Should we make policy concerning this? --Echelon 19:24, 27 January 2006 (PST)

I love the format that theforce.net took with spoilers for the Star Wars movies. You would need to highlight sections of the text to have it appear. Just looking at the page which had a white background would have the "bad stuff" contained in white characters. Highlighting it would make the text appear. A great effective way of hiding information but having it still be accessible without needing to go to a different page. --Mpython 5:36, April 21, 2006

While that works, I don't know that it is ideal, it needs to be really obvious to the reader that something is hidden. Also, those replaying the game don't likely care about spoilers so it's maybe not the best idea to force spoiler selection every single time. I like the idea behind Wikipedia's Dynamic navigation box template], with that it's obvious that something is hidden. Garrett^Talk 15:23, 21 April 2006 (PDT)

Weekly/Monthly SQL dumps

I'd like to do SQL dumps of StrategyWiki every so often so that we ensure that the content of this wiki lives on regardless of anything that happens. With anyone able to freely download the wiki's database, I feel that we would be fully living up to the GFDL. Do you guys agree with this?

Secondly, if we do plan to offer downloads of the database we'll have to figure out the logistics of how to do so. For security reasons, we'll need to make sure tables such as the ones for users and sessions are not included--we don't want password hashes falling into the wrong hands. In addition, offering the downloads may prove to be a large bandwidth problem if many people decide to download it--this may be a false dilemma, but I'd prefer to plan for that scenario now rather than later. What if we only offered the database downloads to the top contributors of this site to oversee and do it in a rotating manner?

In addition to the database, we'll have to do the same for images.

What are your thoughts to all of this? Is it even necessary? --Echelon 21:06, 20 January 2006 (PST)

I'd love to see this.

Brainscatter 15:30, 9 February 2006 (PST)

Sounds like a good idea, and that top contributors part is definitely good. <("<) Alex (>")>

I would also love to see this, I would download the database when i could. Woofcat

I'm going to start providing these now that StrategyWiki has gotten some press. If you have any suggestions on how I should do that, leave me a note. --echelon ^talk 17:39, 21 April 2006 (PDT)

Art/Screenshot of the Week

Feel free to suggest. Upload all of your candidates and post them on the talk page for Main_Page. --Echelon 02:47, 8 January 2006 (PST)

---

Is there an easy way of taking screenshots of games on a gamecube? If so, how?

Well, either a TV capture card or a GameCube emulator. The one costs money and the other's buggy, so take your pick. Garrett^Talk 14:30, 22 April 2006 (PDT)

Licencing: CC-BY-SA instead of GFDL?

Hi,

May I inquire what was the reason to go with the GFDL as a licence instead of a Creative Commons licence such as cc-by-sa?

Thanks, Nyenyec 15:17, 21 April 2006 (PDT)

Well the biggest advantage is that content from other wiki sites (Wikibooks, [Gameinfo], etc.) can be copied here because we all share the same license. However I wasn't here at the time of the decision so the reasoning may be more complex for all I know. Garrett^Talk 17:11, 21 April 2006 (PDT)

GFDL is Wikipedia-compatible, and that was a huge factor. We wanted to remain compatible with the largest collection of open content game information, guides, etc. We want to promote a working relationship between the projects.

Initially I almost considered something of a proprietary dual license that I termed a "community license"--we would place the content under the GFDL and also give the StrategyWiki organization--which isn't even an entity yet--full rights to all submissions. That was intended so that we would have the option of changing to any new or better open media license of the community's choosing in the future without being locked into GFDL exclusively. Basically, all content would still be licensed under the GFDL, but there would also be the option of choosing another license later by community vote. I scrapped that idea because it was too complicated, and I feared it would make users apprehensive.

If and when we gain traction, however, we may be able to ask the community what they think of a relicense or dual license, or even this "community license" that I just talked about. Of course if we decide to do this, the application of it would NOT be retroactive unless we can find the permission of those authors who have submitted work. I would be fine with having all of my work relicensed, and several other StrategyWikians might as well. Others may not, however. Or we may not be able to find them all. Anything we couldn't relicense could be either tagged or rewritten.

We are in an early enough stage to shake things up, but we'd have to have a community consensus. After this Digg thing, I'd like to see what happens to the community. Will it grow stronger? Will we gain more help? Once I have a fuller view of this, we'll probably put this and other issues up for debate. --echelon ^talk 17:27, 21 April 2006 (PDT)

Sidebars

I think that a prudently limited variety of sidebars could be useful in adding to the readability of StrategyWiki. I've added a trial page to display and discuss them. Template::Sidebar2 is based on a design by Mr Wallet, and I thought that it looked pretty cool. --echelon ^talk 19:44, 21 April 2006 (PDT)

Wikibooks bans game guides!

Check out this Staff Lounge posting. After much debate and indecision, the final decision has been made. I've put us forward as a potential new host (and, really, it's only between us or the less-shiny Gameinfo). This may be just the kick-start StrategyWiki needs, but it is a LOT of content to suddenly acquire. Thoughts? Garrett^Talk 03:53, 22 April 2006 (PDT)

Wow! Seriously wow! This is probably the best shot we've gotten so far in gaining support. We really absolutely need to use this to our advantage. It must be stressed that our wiki is already geared towards game guides and that would be a more natural home for Wikibook's guides than Wikia's Gameinfo. We have a much more polished presentation and are 100% tailored to guides. Not only do we stand the chance to gain a lot of new content in this, but we also stand the chance to gain a lot of new supporters! This is so excellent! --echelon ^talk 04:22, 22 April 2006 (PDT)

After checking this out, I wonder what would be the best way to handle this. We could simply copy and paste the pages over, but then we lose the page histories. It was also suggested to do a database dump then combine it with the StrategyWiki database. That wouldn't break anything, would it? Are there tools to do that elegantly? What other pros and cons can you think of, and which would be the best route in your opinion? --echelon ^talk 04:35, 22 April 2006 (PDT)

Merging the databases shouldn't cause any problems, but having said that I've never seen it done. The slower but safer way would be manual and thus more controlled uploading via Special:Import. You can see what the imported histories and their users will look like on this history page and also Special:Contributions/Everlong. Not only does the username link instead to the contributions (just like for an anon IP), the contributions page doesn't even offer a link to the userpage, further emphasising that the user isn't actually here. However Wikibooks has currently disabled history exporting which means you can't just use their Special:Export to get the dumps.

I think the only real problem with merging databases is knowing what page is part of what book. Not all guides use the subpage convention yet so are spread all over everywhere. In some ways I wonder if a better way would be to compose a master list of all guide pages and then assign them to users, who would then sift through their copies of the latest dump and find them.

This would all be SO much easier if Wikibooks allowed history exporting. Hm. Maybe it could be temporarily turned back on for the period in which this move is to take place... I'm not saying a full merge doesn't make sense, but it basically means you alone are sifting through thousands of pages to pick out the game guides. Garrett^Talk 05:17, 22 April 2006 (PDT)

How to transfer

Well, as I've said on IRC the Wikibooks tech guys have refused to re-enable history exporting. However today I found MWDumper, a simple command-line tool that (among other functions) can extract pages from an XML dump based on a filter list. It should be easy to make a full list of pages and then let it crawl through the database dump over lunch or something. After some tinkering it works perfectly. The only slight shortcoming is that the filter file is case sensitive, so it skips anything that has an incorrect capital. Garrett^Talk 04:09, 23 April 2006 (PDT)

OK, check out StrategyWiki:Wikibooks Import List. This is a list I'm gradually compiling in a format MWDumper can understand. Images will have to be handled manually. Garrett^Talk 04:49, 23 April 2006 (PDT)

I see that you are importing the San Andreas Wikibook here. So far I think I have moved about 70% of the material to Strategy Wiki. I know that it's quite important to have the histories of each page but I have edited each page as I moved it (added the bottom navigation, editing spelling/typos and sometimes changed formatting). This would take a long time to get all the pages back to the standard they are now. Is there anyway to just move the history of each page and keep the edited page intact?

I also see that you have copied the first page of the San Andreas guide from Wikibooks and inserted it instead of the previous front page with the reason "moving related sites down, our own content takes priority". Just wondering what that meant because the first page was only our content and had an info box and proper naivgation? Jackhynes 13:48, 23 April 2006 (PDT)

That message was because I imported the San Andreas page as a test, forgetting we already had it! Because my edit over there was slightly newer it took precedence. Importing doesn't overwrite anything though. Any time a Wikibooks edit is newer it's easy to open the history and revert to a revision there (as I've just done, now you've pointed that out). Garrett^Talk 14:15, 23 April 2006 (PDT)

Cheers Garett, that was just what I wanted to here - now I hope all the pages are older! Else I'm gonna have a lot of checking the newer edits then reverting! Jackhynes 14:29, 23 April 2006 (PDT)