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!
- Issue 4 - Spoilers, SQL Dumps, Screenshots, etc. - from Mar/April
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. GarrettTalk 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)
- 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.
- Urg.. I see why some people prefer CC-BY-SA to GFDL. And it's not a nice reality. If that article is true, then we might want to consider some dual-licensing and relicensing in the future. I know it's impossible to change anything we already have to CC-BY-SA, but in the future we might want to make future articles CC-BY-SA. I'd like to hear your opinions on this issue. --echelon talk 23:03, 13 May 2006 (PDT)
- Yes that article captures the gist of it perfectly. I for one would certainly support changing to CC-BY-SA. In addition to the reasons they gave I think its simplicity makes it simple for the average user to understand, and perhaps making them more likely to feel confident about licensing their contributions. However if a change is to be made it must be done NOW. Re-labelling the site itself is the fiddly bit.
- The per-guide implementation however is easy, and can be done via templates. Take a look at the bottom of my user page for an example. Unfortunately IE's hatred of CSS means it doesn't work for it; however this is just the code I had on-hand, there are definitely more compatible methods. Anyway, this means licenses can be added or overridden (a button can be placed over top of another just as easily as beside it) straight from a template.
- Wikinews recently changed their copyright from PD to CC-BY, see their copyright page for more (and especially note the wording of their footer). That might give you some ideas. But, anyway, this is definitely a decision that must be made as quickly as possible to both minimise the workload and also the amount of content under the GFDL. GarrettTalk 02:29, 14 May 2006 (PDT)
- Yes that article captures the gist of it perfectly. I for one would certainly support changing to CC-BY-SA. In addition to the reasons they gave I think its simplicity makes it simple for the average user to understand, and perhaps making them more likely to feel confident about licensing their contributions. However if a change is to be made it must be done NOW. Re-labelling the site itself is the fiddly bit.
- Having this discussion now should be an immediate priority for us. I can't believe I didn't consider the impact of doing nothing about this before. We need everyone who edits here to contribute their thoughts and opinions on this issue so we can make a wise choice. While I'd like to switch licenses now, whatever we do will have a large impact on our future. Picking a license that prohibits multi-licensing and isn't future-compatible will box us into a hole that we don't want to be in. First, let's look at the available options and weigh what each provides for us. We need a long-term solution that will work for many, many years. Perhaps beyond the scope of our own time here, to best accomodate whomever future contributors and users of this project may be.
- If we can't decide on CC or BSD or something else, I also have another possible idea that I had thought about before. What about a "StrategyWiki License" that pertains specifically to the contents of this wiki? We would create this with the future in mind, so that we could predict and adapt to any future legal issues that may arise. Therefore, the first thing we would state is that people can "at their choice, use this version or any later version" of the license. Sort of like the GPL, this gives us future-compatibility. Secondly, we could draw up the terms of the license to be as dual-licensing friendly as we want to be and as copyleft as we want to be. After reading about CC-BY-SA, I feel it is much more open and far less restrictive than the GFDL. Moreover, the most important advantage a custom license would give this project is that the project can adapt--with a custom license, we could retroactively apply important changes to anything licensed under a StrategyWiki license. Older content wouldn't be stuck in the past forever. (So long as that is part of the provisions for contributing.) Older revisions would still be under the license version they were initially published under, but the project as a whole would be under the latest version of the license--this is what I mean by "future expandability".
- Now, there are three problems that come to mind with this (and you may be able to think of more). The first, and greatest, is that the license could evolve into something bad. Who is to prevent this from happening? We could say that the license would be democratic, but there is always a small fear inside me that it could be pulled into the depths of something that takes away usage rights of the public and grants it to some all-powerful group. Think the FSF, who ask all contributors to waive their rights to copyright on all contributed code. Bad, bad, bad! I could only see an FSF scenario becoming more restrictive, more GFDLish. Then again, IIRC, I believe it was the Debian project that manages to do fairly well in licensing? The only goal I am aiming for is to ensure StrategyWiki content is always going to be relevent, useful, and free to use with as little restriction as possible. Is a custom license too bad for its own good? Is it overkill?
- The second disadvantage is that a custom license is unknown. New contributors to our project may see our license, but without the familiarity of Creative Commons, GFDL, or BSD, they won't have a clue whether our license is actually authentic and can be trusted. Or what it states without reading it all themselves.
- The third and final disadvantage of a custom license is that it has to hold up, legally. Who would write it? I'm not a lawyer. Could we just copy from the CC-BY-SA and delete/change what we don't like about it? Or add things we feel are missing? Ths is yet one more question that needs to be answered.
- While a custom license for this project would be a lot of work, I do feel that the advantage of forward-proofing contributions for change of license would be a significant gain that would save us large amounts of trouble in the future. Maybe we could simply state this in an ammendment to a copied Creative Commons license? What are you thoughts? --echelon talk 11:15, 14 May 2006 (PDT)
- Having this discussion now should be an immediate priority for us. I can't believe I didn't consider the impact of doing nothing about this before. We need everyone who edits here to contribute their thoughts and opinions on this issue so we can make a wise choice. While I'd like to switch licenses now, whatever we do will have a large impact on our future. Picking a license that prohibits multi-licensing and isn't future-compatible will box us into a hole that we don't want to be in. First, let's look at the available options and weigh what each provides for us. We need a long-term solution that will work for many, many years. Perhaps beyond the scope of our own time here, to best accomodate whomever future contributors and users of this project may be.
I have several comments but I will try to be concise:
- Creative Commons. I tend to dislike CC licenses because authors tend to choose the noncommercial (NC) variants. If we pick CC-BY-SA, then we do not have that problem.
- Attribution Withdrawl. The CC-BY-SA 2.5 licenses have an attribution withdrawl clause, which appears to agree with the recommendations in the debian-legal Summary of Creative Commons 2.0 Licenses. However, even though Debian thinks that it is okay, I personally dislike this clause:
- If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any credit as required by clause 4(c), as requested. – clause 4(a) of CC-BY-SA 2.5 Legal Code
- Transparent copies. The GFDL requires everyone who distributes "more than 100" copies of a guide to provide a "Transparent" copy (in human-editable text such as the MediaWiki markup, not in generated PDF or Microsoft Word). The CC-BY-SA seems to lack that requirement, which is another reason why I normally prefer the GFDL. However, I only care that this wiki has a Transparent version. If we always use MediaWiki, I can Special:Export/Main Page and get the wiki markup, even if wiki is CC-BY-SA.
- Custom license. The text of the CC-BY-SA 2.5 is itself under in the public domain: "We do not assert a copyright in the text of our licenses. So yes, CC will let you edit the CC license to make a new license.
- Dual-licensing. It might make sense to declare that after date X, all contributions to StrategyWiki must be licensed under both the GFDL and CC-BY-SA. However, date X would have to after whenever we finish importing Wikibooks content.
My recommendation? Stay GFDL; or switch to a dual-license between GFDL and CC-BY-SA. --Kernigh 12:32, 14 May 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? GarrettTalk 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)
- Thanks to this move, I showed up :). I'm hoping to help in that transition (I did quite a bit to SM64 and Super Mario world as well as the FFVII guides there :). Mason11987 17:46, 24 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)
- (this problem has been resolved, see StrategyWiki:Wikibooks Import List)
I'm a wikibooks user (from the MapleStory book) and I've been looking around this site a bit considering that it is one of the main choices of where to move that book. It looks like it could become very popular. I was looking at that page you moved over as a test and I'm slightly confused as to what to look for. It was also mentioned that images had to be moved manually (discussed lower down). What about templates and talk pages? About the wikibooks tech guys not wanting to enable history exporting, perhaps they would be willing to take a list of pages that need to be dumped and send the file(s) directly. I have put up a note on the wikibooks MapleStory talk page about moving the book here. If it is decided to move the book here, what would need to be done to make the transfer as quick and easy as possible? Sorry about this post being essentially a bunch of random disorganized thoughts, but I hope it makes sense. -- Prod 22:29, 2 May 2006 (PDT)
- The above discussion was rather out of date. Since that time I found a solution. I just take the latest dump, run it against a list using MWDumper, and then upload the result via Special:Import. It's only images that have to be done manually, everything else (even the image description pages) is included in the dump. All I'll need is a list of all the pages, templates, and image description pages you want imported. MWDumper automatically extracts matching talk pages, so you don't need to worry about listing those. GarrettTalk 00:28, 3 May 2006 (PDT)
- OK. At the moment, there is still a bit of discussion about where to move the MapleStory book. If it does move here, where would you like the list of pages that need to be moved? -- Prod 11:07, 4 May 2006 (PDT)
- StrategyWiki:Wikibooks Import List/MapleStory would do nicely. You can easily get a list of pages from Special:Allpages over there, it's only the templates and images I can't easily track down using that method. GarrettTalk 13:46, 4 May 2006 (PDT)
- OK. At the moment, there is still a bit of discussion about where to move the MapleStory book. If it does move here, where would you like the list of pages that need to be moved? -- Prod 11:07, 4 May 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. GarrettTalk 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. GarrettTalk 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). GarrettTalk 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)
Screenshots
What is the situation on screenshots. For one reason or another I know wikipedia doesn't like having a lot of screens in a page, but I think having plenty (although not a huge amount) of images in a guide is extremly useful. Is there some legal restriction which caused wikipedia's stance which is related to the GNU FDL license that you share with them? Or is it a site-specific decision?
I'm just wondering because I recently saw about a dozen (small) GTA images uploaded which will be used on a guide I presume, and I was thinking that I might want to break out my Super Mario World and throw in screenshots for the tricky parts of the game, and that's just one example. Since FFVII will probably be imported I won't be able to do a lot with it (although I did have several edits to it at wikibooks :)), but there are a bunch of other games I already saw that I could add to. And maybe I can help you guys structure the site a little better? I've had experience on a SporeWiki.com where I am a Bureaucrat, and when I first arrived there I completly revamped the organization scheme, so I think I can helpful in that as well. But I'm particularly interested on your ideas on screenshots, so let me know. Mason11987 17:55, 24 April 2006 (PDT)
- Wikipedia's screenshot restriction was centered around the very touchy concept of "fair" use for educational purposes. A strategy guide is generally considered stronger fair use than an encyclopedia as the whole work is basically showing how cool the game in question is. As long as the screenshots have a clear purpose and aren't just to look pretty it should be fine. Anyway it's good to have others with experience around. Besides, I don't see any company complaining against fansites hosting quadrillions of images... :) GarrettTalk 19:53, 24 April 2006 (PDT)
- Awesome, thanks for clearing that up :). Mason11987 12:27, 25 April 2006 (PDT)
- I'd definitely think that as long as the screenshot is relevant, and you don't overdo it, it'll fall under Fair Use. Hell, people have even done video walkthroughs - those're what, 24 screenshots per second? --aniki21 03:14, 27 April 2006 (PDT)
Comments from a Wikibooks User
Your flagship page, Zelda: Ocarina of Time, has a few formatting issues-I would make the introductory page the table of contents, or perhaps combine it with your little intro page, as it is you have to scroll back up to the top to navigate anywhere, same thing applies to the walkthrough, forcing them to navigate to a new page is kind of annoying.
I've worked on the FF6, Chrono Trigger, FF7, and Quest for Glory wikibooks, the first three are fairly complete content-wise but could use some more media and tables to flesh them out.
If the Wikibooks are going to be exiled here, we'll have to see what we can do. The advantage wikibooks had was that it's a sister project to wikipedia and a natural place to look for more detailed information or for people wanting to add to the general body of knowledge. At the moment, your website is the second google hit for strategy wiki, behind an encyclopedia entry for the site itself. If you want to attract people you'll need a lot more content, particularly on recent games, and attract people willing to contribute over the wiki format.
It'll probably take some advertisement and cross-polination across all the other sources for game guides to try to promote this format. The best thing you could do would be to tie it in to Wikipedia directly to redirect people looking for more info, but that may not be likely.--BigCow 13:53, 25 April 2006 (PDT)
- So you're suggesting Template:All Game Nav be repeated at the bottom? That's a good idea (although it will need some formatting changes, or possibly even a separate closing template). As for advertisement, once the Wikibooks content is in full lockdown both its pages and Wikipedia's will be changed to link to mirror(s). Right now this is the only wiki I'm aware of that's intending to fork the content (barring complete forks like Wikibooks.net, which will likely purge their copies at some point anyway) which means we'll get all the incoming Wikipedia attention. The only downside is we don't get a pretty sidebox in the external links section. GarrettTalk 16:38, 25 April 2006 (PDT)
- Not only that, but the idea of an intro page to get to your content is an annoying one. The introduction pages for the guides themselves and the walkthrough pages don't really serve a purpose, and should just be merged with the table of contents so they can navigate whereever they want after clicking a guide.--BigCow 09:47, 26 April 2006 (PDT)
- Less clicks are always better. -- Mason11987 (Talk - Contributions) 11:46, 26 April 2006 (PDT)
- The idea of the cover page was that it was more like a print strategy guide, but yeah I guess it's mostly for looks and not usefulness... still, this is a major enough change it will need a vote or something, or at least some more feedback from others. GarrettTalk 16:14, 26 April 2006 (PDT)
- A page in a strategy guide is very different than a page on the web. A chapter in a strategy guide could be a single web page, since a web page can span multiple pages of text and images. Your walkthrough pages actually do a good job with this, but you don't need an intro page before you see the actual content, you should scroll down to see the table of contents rather than clicking through it.
- The idea of the cover page was that it was more like a print strategy guide, but yeah I guess it's mostly for looks and not usefulness... still, this is a major enough change it will need a vote or something, or at least some more feedback from others. GarrettTalk 16:14, 26 April 2006 (PDT)
- I'd be up for putting it to a vote or getting some more feedback, particularly since you want to use this book as the standard.--BigCow 17:53, 26 April 2006 (PDT)
- I have to agree with BigCow. So far, the intro pages only cause me trouble and discontent, and I agree they serve no purpose other than looking pretty. If we are going to become the standard, then we need to focus on getting results and looking pretty at the same time, whereas the intro pages only serve for the latter. I highly doubt that anyone is going to save the entire guide in .pdf format and print it, so cover pages are rather pointless. I agree that a vote should be made, sooner the better. Cosmo 12:09, 27 April 2006 (PDT)
- Anyone with the authority or ability to do this? The longer we wait, the more has to be changed.--BigCow 12:06, 9 May 2006 (PDT)
Input needed
Input needed in three places: Category talk:Nintendo DS, Category talk:Game Boy Advance, and Category talk:Game Boy. -- Mason11987 (Talk - Contributions) 17:02, 25 April 2006 (PDT)
Categorization
As can be seen by anyone who is watching the RC, I am a fan of categorization. I think it would be best if we had 3 root categories for the actual content here which will be interconnected. Category:Game System, Category:Game Genre, and Category:Game Company. They'll be connected because some game companies will make game systems (and therefore the game system will also be a subcategory of the game company who makes it [NES is a subcat of nintendo for example]). Now, we also have a lot of uncategorized categories like VTech or Commodore (and yes, I do realize they will almost never be used) which are "console makers". I'd like to categorize them, as well as the nintendo, sega, sony, M$, and other console makers into some category which would encompass all game system makers. I don't know what to call it though, so I thought I'd throw it out there. Console makers isn't really applicable because I want people who only made handhelds to be on there too, maybe "system makers" but that sounds retarded. So what are your thoughts? -- Mason11987 (Talk - Contributions) 10:43, 27 April 2006 (PDT)
- Sounds like a good plan. But again, why not just System, Genre and Company? Since most system makers produce games for their own platforms that could be all-encompassing... of course it could then have Game Company and Platform Company as subcategories, but then you're back to the retarded name problem. :) GarrettTalk 14:26, 27 April 2006 (PDT)
- Ah, that's a good idea...I think that would be better. Before I go changing everything again, do you think it'd be best to call the categories "Category:System" or "Category:Systems" and so on for the other two? -- Mason11987 (Talk - Contributions) 07:02, 28 April 2006 (PDT)
- Hmm... so far we've got singular for genres (e.g. Category:FPS), but in this case I'd say it might as well be plural. Either way it's a very nitpicky thing. GarrettTalk 19:10, 30 April 2006 (PDT)
- True, just figured I'd throw it out there :). -- Mason11987 (Talk - Contributions) 08:16, 1 May 2006 (PDT)
- Hmm... so far we've got singular for genres (e.g. Category:FPS), but in this case I'd say it might as well be plural. Either way it's a very nitpicky thing. GarrettTalk 19:10, 30 April 2006 (PDT)
- Ah, that's a good idea...I think that would be better. Before I go changing everything again, do you think it'd be best to call the categories "Category:System" or "Category:Systems" and so on for the other two? -- Mason11987 (Talk - Contributions) 07:02, 28 April 2006 (PDT)
Copying images from Wikibooks, Wikipedia
I recently used User:File Upload Bot (Kernigh) to copy 80 screenshots that I made for NetHack and originally submitted to Wikimedia Commons for use in Wikibooks. Currently I have both a download bot and upload bot for MediaWiki. Thus I simply give the list of files to the download bot and have it automatically download the images and their descriptions from Commons, then give the folder of images to the upload bot and have it automatically upload the images to StrategyWiki. (I also have the option of editing the image descriptions between the download and upload.) Earlier today, my bot took over both Special:Recentchanges and Special:Newimages.
I suppose that I could point my download bot at Wikibooks or Wikipedia, and use it if someone needs large numbers of game images moved from either wiki. (Most game images are fair use, so they are not on Commons.) I might also be able to make the perl scripts (my hacked version of Commons:File upload service/Script) available. --Kernigh 20:16, 30 April 2006 (PDT)
- Actually, so far I've come across very few images. It seems NetHack is by far the most heavily illustrated. But thanks for the offer, and if I come across something major I may call on you then. :) GarrettTalk 19:28, 1 May 2006 (PDT)
- Have you looked at the MapleStory monsters list? I think that qualifies as major :P -- Prod 21:54, 2 May 2006 (PDT)
Transwikification EQ from wikibooks
Greetings :) here a repost from what I just put on the EQ discussion page
"looks like the transition from wikibooks went smooth (granted, some pics didn't come across yet, but we'll get that sorted some stage). what surprised me though was, that I wasn't aware of the change (did I miss something here?). was there an announcement? I always though that things like that should at least be announced on the discussion page i.e. (no vote necessary really from my PoV, but not even an annnouncement?). also, what I hate now is, to get all those pages watched again, which is a pita somehow...but hey..:-( --Kajolus 05:07, 11 May 2006 (PDT)"
in addition: Now I learned, that some other person (User Tendiin, wikibooks) is not able to contribute to the EQ wiki anymore (firewall access issues)...even worse, as he was picking up speed...is there anything we can do?--Kajolus 05:36, 11 May 2006 (PDT)
- Bah, I knew I'd slip up eventually! :( Anyway, the official policy change has been being discussed for close to a month now at the Staff Lounge, although the issue had been brought up on and off for a good year beforehand. I decided to start moving the stagnant guides and worry about the active ones later, so that as much was dealt with as possible before any deadlines arose to complicate matters further. Yesterday I made another big effort, and it seems in all that busyness I forgot which ones I'd identified as still active! So, er, sorry! :(
- As for re-watchlisting this list will help. You'll also find some pages on that list that seem to have become orphaned from the rest of the guide. You may also like to turn on "Add pages you edit to your watchlist" (under Editing in Special:Preferences).
- As for the firewall, hm... echelon might have some ideas. It seems strange that Wikibooks can get through, although it could be that the firewall specifically allows Wikipedia, and thus anything else Wikimedia is hosting works too.
- So, anyway, I hope that explains everything. GarrettTalk 21:08, 11 May 2006 (PDT)
Template:Title
This might be useful to some people...
If you need an explanation, let me know :). Hope you like it.
stolen from [1] :). -- Mason11987 (Talk - Contributions) 15:18, 9 May 2006 (PDT)
Auto-linking large pages, and Intro Pages
Two things, judging by the recently trans-wiki'd Chrono Trigger guide it looks like strategy wikis doesn't automatically link pages over the 32kb limit, setting them as edit links instead. Any way to fix this? Also, getting a decision on having intro pages that force the user to click through them to get any content would be helpful. --BigCow 10:53, 11 May 2006 (PDT)
- No, that's because I checked it over while importing other pages. Doing so cached the redlinked copy. It's just how things have been configured. GarrettTalk 23:35, 11 May 2006 (PDT)
In Favor of eliminating intro pages/merging them with the table of contents
- For - The intro pages, while they look nice, serve no immediate benefit to the reader. They do not improve organization (as having multiple pages does) and they do not make it easier to find information. Everything in a wiki designed for strategy guides should revolve around the easiest and most complete way of guiding the users of the wiki. In that sense if a piece of the wiki would better benefit the user if it were changed, then it should be so, especially if it is no great burden to the editors (in this sense, it would take LESS work to make intro-less guides). So I see no reason for intro pages to exist and I think the first page of a guide should have a brief intro of the game, and a set of as many other useful links as possible, organized as well as possible. -- Mason11987 (Talk - Contributions) 13:14, 11 May 2006 (PDT)
- For - Mason said it well. Having to click through intro screens is poor web design. You should scroll down to see more content, not have to navigate to another site which has the content you actually want to see. The first page of a guide should be like a portal, linking you to all the places you might want to visit, and providing some information to make that process easier.--BigCow 15:29, 11 May 2006 (PDT)
- For - yeah, pretty but pointless. {{All Game Nav}} may become a little empty though... unless the game name and Table of Contents both link to the guide's main page. GarrettTalk 23:35, 11 May 2006 (PDT)
- For - I never actually saw the point in them, honestly. Cosmo 07:29, 12 May 2006 (PDT)
- For - works good for the super smash bros melee page: Super Smash Bros. Melee. --blendmaster 13:26, 13 May 2006 (PDT)
- For - Not only have you proved to me that these are redundant, but I have just realized that we may actually want to host more than one type of guide. (I'll start a new topic for this in a moment.) --echelon talk 22:49, 13 May 2006 (PDT)
Opposed
Undecided
As of right now, I must say that I am wholly undecided on this issue. I am awaiting arguments from both sides. --echelon talk 12:16, 11 May 2006 (PDT)
- I used Template:Cover in NetHack because Zelda: Ocarina of Time is using it. It works somewhat well because clicking the image leads to the table of contents (TOC). I would like to just keep having separate covers and TOCs, but there are benefits to having one page as Super Smash Bros. Melee does, and if covers and TOCs do remain separate, we might want to add more links on the covers. --Kernigh 14:00, 13 May 2006 (PDT)
Multiple types of guides
I was just thinking about the possibility of hosting multiple guide types. Many at Gamefaqs have criticized this project for not supporting more than one type of guide. Though I still stand completely firm about no redundancy in this project whatsoever, I can imagine different types of walkthroughs being made. For example, there might be a speed run walkthrough to supplement the regular one. I do not see these as repeating anything, but simply "branching" from the main guide. What do you think? If we do implement this, it may require we change some things about our URL and article naming policy. --echelon talk 22:57, 13 May 2006 (PDT)
- It'll be kind of an inevitability if the site gets popular enough that people will have more than one type of content they'd want to host, but I think that could still be handled with one main guide. Consider the typical types of guides featured on GameFAQs:
- Boss FAQs/Strategy FAQs against the weapons in FF7 for example: covered under our system, since we have more sub-pages than just a walkthrough.
- MiniGame Guide: Same thing, see the imported Final Fantasy VII guide.
- Game Script: These would actually be nice to have, but they could work as sort of an "Additional Content" thing under the main guide, kind of like a Plot FAQ again.
- Specific Character Guides for fighting games like smash bros, same kind of thing
- Maps/Charts: Integrated into the walkthroughs or given their own section
- Speed Run/Low Level Guides: these are the hardest since they're often a complete departure from a normal walkthrough, and they can be an entire walkthrough of the game with a specific goal in mind. I'd prefer to give them their own section underneath the main guide, as in something like Chrono Trigger/Speed Run/Introduction or something similar. Basically make them a subpage.
- The main problem we might have is that people might have very conflicting strategies for a game like Starcraft, or even something like Final Fantasy VIII about the best tactics to use or way to build levels. In some cases we may just need to list multiple strategies or link to different pages which describe different approaches, a Starcraft Guide might have some sub guides on teching, rushing your opponent early, etc.
- Our table of contents could read like a complete GameFaqs list of guides, with the advantage of having no redundancy. They would link Plot FAQs and Boss FAQs as separate guides, we'd just consider them to be a part of a single complete guide.--BigCow 00:30, 14 May 2006 (PDT)
- Game scripts would be another good idea, but that's not possible under the GFDL (where all content must be either GFDL or the precarious "fair use"). Changing to CC-BY-SA would free up multi-licensing some. GarrettTalk 03:39, 14 May 2006 (PDT)
- I don't think there's any need for more than one guide hub though. Maybe a separate TOC for each walkthrough type, but certainly not a completely separate guide. Supages make that unnecessary. GarrettTalk 03:37, 14 May 2006 (PDT)
- Yeah, I so no need for something like Metroid Fusion (speed run) and Metroid Fusion (1% run) at all, when they can be subpages, as Garrett said. I was thinking of implementing those after I finished my work on MF, as optional quests towards the bottom of the TOC. Cosmo
- (I've also added seperate map pages within the guide for things like getting 100%.) Cosmo
Vandalism comes to StrategyWiki
At 13 May, this user dropped photos of penis on several pages, mostly in the RuneScape guide: Special:Contributions/P0op0o.
Sysops, please delete the two images uploaded by that user. I would also consider an infinite block. --Kernigh 10:47, 14 May 2006 (PDT)
Planning to host DB dump soon
Just a note: I'll be busy much of the week, at least until Wednesday or Thursday. Soon thereafter I am planning to host a tar.bz2 archive of the StrategyWiki database and a seperate archive of our uploaded images/files. I am going to begin on a once a month schedule where I supply a full backup (Minus the user table for security concerns) of everything. This helps to both preserve the content of the website, should anything unfortunate ever occur, and also to aid in distribution. Once we become popular enough, I do believe websites will want to mirror our content, much like Answers.com does for Wikipedia. I look forward to that day when we have become the de facto, and it will make me happy that we've provided such a valuable resource.
The archive files will be located on this server (we have plenty of bandwidth). If you would like to provide suggestions to me on alternative methods of distribution (torrent, mirrors, etc.) let me know. I hope you will all download a copy for safe keeping. --echelon talk 09:51, 15 May 2006 (PDT)
- I would like to add that as our rate of growth increases, so will the rate of publically available backups. Currently, a once-monthly schedule should suffice unless we can automate it without a big impact to the performance of the site. Note that in addition to this, I personally keep full, regular backups on hand; I may soon make those available to Garrett and any future admins for the safety's sake. --echelon talk 09:58, 15 May 2006 (PDT)
The Front Page! (agh)
Every time I look at the front page, it's basically the same. The Digg stuff is fine with me, but the screenshots of the week thing needs to be updated more often or replaced. I'll do it if I have to.
Also, the Zelda screenshot says "Celda!" - Garrett told me in #strategywiki once that this is for "cel-shaded Zelda" but to me it's a glaring typo, and it may give people the idea that guides here are chock-full of typos.
This may be nothing to you guys, and if so, then okay, I can drop it - but it's really driving me mad, and I am not even mentioning the 'current' collaborations. If you need more screenshots or game artwork or anything, I will find it for you! I just really hate static home pages.