Project Overhaul Dolphin Wiki

[wildgoosespeeder]

(11-10-2015, 05:17 PM)KHg8m3r Wrote: I think instead of changing everything so radically, just educate people on how to edit the Wiki. Like a page saying how things work and how to edit.

A page like that already exists but it isn't very well-followed and it is kind of hard to find. The template should reinforce the conventions on the game page you are viewing instead of a page elsewhere on the wiki.
https://wiki.dolphin-emu.org/index.php?title=Project:Wiki_Conventions

Ideally, the banner (appearance subject to change) should look like this:
https://wiki.dolphin-emu.org/index.php?title=RatingProblemFix/sandbox#Testing_Found_Bug_Report_and_Revision_Fix

(11-10-2015, 11:45 PM)JosJuice Wrote: I don't see how that is a response to my question. What you and MaJoR were talking about there is about the risk of duplicate issues being created. I agree with MaJoR in that it would create more maintenance work for us on the bug tracker, but what I was talking about has nothing to do with duplicates. My concern is that some of the issues that are listed on wiki pages (like EFB2RAM being required) aren't Dolphin bugs at all but rather problems with the user's configuration. Such issues are good to list on the wiki but are completely inappropriate for the bug tracker. Your system is designed so a wiki issue that does not have a bug report counts as incomplete (i.e. shows the "Create/find bug report" message and makes the page show up in Categoryages with missing bug reports). This incompleteness can only be resolved if a bug report exists, but bug reports for this kind of issues are invalid and will not be accepted on the bug tracker. If your system succeeds in making people create more bug reports (I don't know if it will or not), this is going to lead to users cluttering the bug tracker up with useless issues for no good reason. The wiki needs to take into account that some issues simply aren't meant to have bug reports.

I'm sure that you hate getting duplicate reports. Trying to reduce that while at the same time keeping track of already known bug reports. Test it yourself by looking at the following page. Click the link that will take you to the bug tracker (remove "/sandbox" as if this were deployed on the real page, it wouldn't be there):
https://wiki.dolphin-emu.org/index.php?title=Super_Smash_Bros._Brawl/sandbox

The impression that I am getting so far is that the ultimate goal of Dolphin will run all games on default settings in the most optimal way possible without accuracy loss and without deviation from default settings that impact performance. Revision 4.0-7664 fixes the need to use EFB2RAM for F-Zero GX as EFB2Texture is a more optimized mode (I read the blog about garbage collecting GPU RAM). Also Game Boy Player has a report because of missing accessory support:
https://dolp.in/i2163

(11-10-2015, 11:45 PM)JosJuice Wrote: I don't understand the point of assigning ratings to issues on the wiki, by the way. Users can already read the text and understand how serious "the game crashes" is in comparison to "the reflections on Termina Bay are a bit off". In fact, reading the text can even be better because it lets the user decide how serious the issue is to them instead of having an arbitrary scale of seriousness. I'm not saying the idea is completely worthless, but the advantages seem to be much smaller than the maintenance cost that's needed.

Instead of reading text only, colors are an easier to understand and more direct way to assess how problematic the issue is and conveys how deviating from the highest accuracy settings would impact your ability to play the game. I'm trying to adopt a scheme similar to the 5-star system to rate overall compatibility games have with Dolphin but for each individual problem instead. As for maintenance, the idea is to reduce it by flagging when something is missing. Initial deployment will have to go through so many edits on existing populated problems sections but that is just getting it up-to-date. The Wiki doesn't seem to have a way to tell if something is missing. I'm trying to balance the maintenance issues out so that way maintenance is useful instead of dreaded. I am also trying to correct years of increasing trouble to keep things up-to-date.