Open Registry of Game Information 

  • Contribution process

  • Talk about specific features of our upcoming online game database.
Talk about specific features of our upcoming online game database.

Moderators: MZ per X, gene

 #37548  by jotaroraido
 20 Nov 2013, 02:45
[This thread has been created as a "split" from this thread]


gene wrote:3. Accepting contributions.
We need a detailed workflow description before we can start to implement something for this. For this we would need the experience of Mobygames/TheLegacy/other game databases users who know their workflows and are willing to help us in building a better one :mrgreen:
I think the approach that Discogs uses might be applicable here: any registered user can directly edit any entry on the site, or add a new one, but those changes are marked as "preliminary" and highlighted in a different color in the client until they've been "approved" by a trusted user -- or approver to use the old MobyGames terminology. Preliminary data could be hidden from unregistered users (and users who choose to hide it) until it's been approved. This would keep any potential vandalism or abuse out of the general public view.

I'll draft up an example workflow for some of the more common scenarios in the coming days.
 #37550  by MZ per X
 20 Nov 2013, 12:12
jotaroraido wrote:Preliminary data could be hidden from unregistered users (and users who choose to hide it) until it's been approved. This would keep any potential vandalism or abuse out of the general public view.
This is an important point. Just to give a little perspective, Oregami will be run by a German non-profit, and the German word for non-profit is "gemeinnützig" which literally translates to "serving the public good".

So when I checked our charter draft with the financial authorities for a possible non-profit status, I was clearly told that for "serving the public good" the data on our site should to be as accurate as possible. Otherwise the advantages of the German non-profit status would be harder to justify.

So, what I want to say, if we go for free editing, we need to hide the unaccepted changes for unregistered users, and should default to hiding it for newly registered users.
 #37560  by Tracy Poff
 20 Nov 2013, 18:42
MZ per X wrote:
jotaroraido wrote:Preliminary data could be hidden from unregistered users (and users who choose to hide it) until it's been approved. This would keep any potential vandalism or abuse out of the general public view.
This is an important point. Just to give a little perspective, Oregami will be run by a German non-profit, and the German word for non-profit is "gemeinnützig" which literally translates to "serving the public good".

So when I checked our charter draft with the financial authorities for a possible non-profit status, I was clearly told that for "serving the public good" the data on our site should to be as accurate as possible. Otherwise the advantages of the German non-profit status would be harder to justify.

So, what I want to say, if we go for free editing, we need to hide the unaccepted changes for unregistered users, and should default to hiding it for newly registered users.
I still need to do some research on Envers, before I can make a more detailed proposal, but:

While I think that unapproved changes should not appear on the live site in place of approved data, I think it is important that the details of proposed changes should be publicly visible. That will serve several purposes: reducing duplication of work, allowing public comment, generally increasing transparency of the process.

I have an idea for a technical solution, but it may require us to roll our own Envers-like software, which would be suboptimal.
 #37562  by MZ per X
 20 Nov 2013, 18:55
Tracy Poff wrote:While I think that unapproved changes should not appear on the live site in place of approved data, I think it is important that the details of proposed changes should be publicly visible. That will serve several purposes: reducing duplication of work, allowing public comment, generally increasing transparency of the process.
I second this. If we'd do a Moby-like system, I'd suggest public queues where ~everybody (maybe no anonymous users) can make comments, and approvers can activate the data for the live site. Furthermore, it would be helpful if important data (say a new platform) would need more than one approval, or at least a mandatory forum thread for discussion, somehow integrated in the contribution process.

I think we should open a new thread for this discussion. :)
 #37590  by jotaroraido
 22 Nov 2013, 00:08
MZ per X wrote:Furthermore, it would be helpful if important data (say a new platform) would need more than one approval, or at least a mandatory forum thread for discussion, somehow integrated in the contribution process.
I'm not entirely sure that would be worth the extra effort. I'm struggling to think of a situation other than new platforms where we would need such functionality. For new platforms, it could be that admins (and possibly trusted users) could add them directly, with policy stating that we would only do so after reaching a consensus in discussion prior to implementation. There's no point in building an extra system that would be so rarely used.

The only other situation that comes to mind is edit disputes, which again, could be discussed on the associated talk threads for the game/company/person in question. Ideally, a semi-moderated format as proposed would limit these situations as well.
 #37592  by Ultyzarus
 22 Nov 2013, 01:29
jotaroraido wrote:
MZ per X wrote:Furthermore, it would be helpful if important data (say a new platform) would need more than one approval, or at least a mandatory forum thread for discussion, somehow integrated in the contribution process.
I'm not entirely sure that would be worth the extra effort. I'm struggling to think of a situation other than new platforms where we would need such functionality. For new platforms, it could be that admins (and possibly trusted users) could add them directly, with policy stating that we would only do so after reaching a consensus in discussion prior to implementation. There's no point in building an extra system that would be so rarely used.

The only other situation that comes to mind is edit disputes, which again, could be discussed on the associated talk threads for the game/company/person in question. Ideally, a semi-moderated format as proposed would limit these situations as well.
We at least need a better system than the escalating at MG.
 #37593  by jotaroraido
 22 Nov 2013, 02:13
Ultyzarus wrote:We at least need a better system than the escalating at MG.
Ideally, the system would allow public commenting on each submission, which would be archived along with the submission itself after approval. Combined with public threads for each game, company, and developer, the design already helps prevent the escalation limbo we had things wind up in at Moby. Of course, a large part of that problem also came from technical issues and poorly-defined policies.

What would be nice and useful though would be the ability to display pending submissions that have no comments, *or* pending submissions that have comments, in addition to listing *all* pending submissions. Also with options to limit by submission type/platform of course.
 #37598  by Ultyzarus
 23 Nov 2013, 15:52
jotaroraido wrote:
Ultyzarus wrote:We at least need a better system than the escalating at MG.
Ideally, the system would allow public commenting on each submission, which would be archived along with the submission itself after approval. Combined with public threads for each game, company, and developer, the design already helps prevent the escalation limbo we had things wind up in at Moby. Of course, a large part of that problem also came from technical issues and poorly-defined policies.

What would be nice and useful though would be the ability to display pending submissions that have no comments, *or* pending submissions that have comments, in addition to listing *all* pending submissions. Also with options to limit by submission type/platform of course.
I already suggested having hard copies of sources archived and available for users. Of course it would be a bit more trouble to submit, but it would ensure that the source stays available in the far future.
 #37602  by jotaroraido
 24 Nov 2013, 04:49
Ultyzarus wrote:I already suggested having hard copies of sources archived and available for users. Of course it would be a bit more trouble to submit, but it would ensure that the source stays available in the far future.
By "hard copies" I hope you don't mean actual printed, paper copies, because that would be a terrible idea and a massive waste of resources. However, if you mean "all past submissions are publicly viewable", then that I agree with that completely. I don't see how it would impact the submission process at all for users, though the system would definitely need to be designed with that in mind -- and I'm going to guess it will be, seeing how important transparency is. :)
 #37603  by Ultyzarus
 24 Nov 2013, 14:14
jotaroraido wrote:
Ultyzarus wrote:I already suggested having hard copies of sources archived and available for users. Of course it would be a bit more trouble to submit, but it would ensure that the source stays available in the far future.
By "hard copies" I hope you don't mean actual printed, paper copies, because that would be a terrible idea and a massive waste of resources. However, if you mean "all past submissions are publicly viewable", then that I agree with that completely. I don't see how it would impact the submission process at all for users, though the system would definitely need to be designed with that in mind -- and I'm going to guess it will be, seeing how important transparency is. :)
Publicly viewable, with saved screenshots of those sources.
 #37614  by Tracy Poff
 25 Nov 2013, 23:07
Ultyzarus wrote:Publicly viewable, with saved screenshots of those sources.
Rather than archiving screenshots ourselves, I'd say we'd be better off working to have durable links to sources. In the case of web sites, a link to a copy of the site in the Wayback Machine is likely to be at least as durable as Oregami. If WebCite gets enough funding to carry on with its work, it would be a great tool for us as well.

If the source is a game screenshot, for example in the case of credits, we might well keep those screenshots just as we would any others. Actually, it occurs to me that we might do well, if we're keeping screenshots of games at all, to have a data field describing roughly what is depicted--title screen, menu, options screen, ending, credits... this bears further consideration.
 #37615  by jotaroraido
 25 Nov 2013, 23:45
One problem that immediately jumps out to me for including credit screenshots with normal screenshots is image quality. Personally, most of my credits are for games I don't own and have never played, where I've used a Let's Play or other similar video on, say, Youtube, World of Longplays, or Nico Nico Douga to source screenshots of the end credits. Good enough to extract the data, but almost certainly not to display alongside direct-capture, emulator, or in-game screenshots, as they tend to be rather blurry and full of compression artifacts.

Having them directly attached to a credits listing -- say, a "source images" button at the bottom of the listing, which would presumably display a gallery similar to the screenshot gallery -- would make the most sense to me. It would also prevent any confusion as to what images go with what listings, and also account for, for example, manual or box scans, or screenshots of a hex editor for extracted credits.
 #37634  by Tracy Poff
 27 Nov 2013, 00:55
jotaroraido wrote:One problem that immediately jumps out to me for including credit screenshots with normal screenshots is image quality. Personally, most of my credits are for games I don't own and have never played, where I've used a Let's Play or other similar video on, say, Youtube, World of Longplays, or Nico Nico Douga to source screenshots of the end credits. Good enough to extract the data, but almost certainly not to display alongside direct-capture, emulator, or in-game screenshots, as they tend to be rather blurry and full of compression artifacts.

Having them directly attached to a credits listing -- say, a "source images" button at the bottom of the listing, which would presumably display a gallery similar to the screenshot gallery -- would make the most sense to me. It would also prevent any confusion as to what images go with what listings, and also account for, for example, manual or box scans, or screenshots of a hex editor for extracted credits.
I had to spend a little time thinking about this, since of course you're right--the issue is a bit complex.

My guiding principle was that we should leverage the tools we're already building wherever possible. If screenshots of the game are useful as verification of details about the game, I don't think that it's unreasonable to store them right alongside the other screenshots. Perhaps someone will find them useful who wouldn't have encountered them if they'd been only in the source information section for the credits, or whatever. Similarly, if we're storing box scans anyway, and if a box scan is the source of some data, we might as well simply link to our copy of the box scan, rather than storing another copy.

But, you're right, too, that in the case of low-quality screenshots or videos we might not really want to store them with regular screenshots, even if they are useful for verification. I'm not sure what the right balance will be, myself.

There is one issue. We've all generally agreed (I think?) that we should be very upfront about the sources of our information, so that people can judge whether it is reliable, as well as for purely academic-integrity-related reasons. How do we envision doing this? Because just a 'source images' section won't really be enough.

An anecdote: for some open source game (Neverball, perhaps?), I contributed information about its release dates, or patches, or something (don't have a copy of my own submission comments, so please forgive my vagueness) which I got by looking through its SVN history to see when the different releases were tagged. It's a pretty straightforward process, but I think that it probably wants a little bit more explanation than just a screenshot of a console window with 'svn log' run in it.

Similarly, I think that your example of using a hex editor to find credits will probably deserve more than just a screenshot of a hex editor, too.

So, however we deal with sources, we should certainly have at least the ability to write some text about them. In that case, I don't think it would be wrong to write something like: "These credits are taken from the staff roll displayed upon completing the game. A (low-resolution) video of the staff roll is available here." In that case, the actual source of the credits is clearly described, so that even if the video goes offline, we will still know where they came from, and the link is provided as a convenience. Ideally, of course, we should provide the most durable possible links. Honestly, I believe that even if we're very successful, something like the Internet Archive is likely to be more durable than Oregami (and they do, in fact, host longplays).

This discussion about sources is complex enough that it probably deserves its own thread. If someone has better ideas than me about how to do sources, I'd love to hear them.
 #37635  by jotaroraido
 27 Nov 2013, 01:53
Well, obviously there should be support for displaying all parts of a submission, not just the attached images. I could directly attach screenshots of credits from a longplay, include links to the longplay on World of Longplays, Youtube, and Archive.org, and add in the comments that they're from the 1992 US release of the game, and appear in the video starting at 52 minutes. If they're credits extracted using a hex editor, I could say what the version of the ROM file is, including a checksum, and the address in the file that the extracted data is from. All of this should be visible to anyone who wants to see it, but it shouldn't necessarily clutter up the display of the information itself -- in this case, the credits listing.

If we're including screenshots of the credits along with all the other screenshots for display, then they should obviously be to the same standard we would require for other screenshots. I agree in the case of the box scans, though -- though on Moby I often found it simpler to just attach the scan to the submission anyway, rather than linking to one elsewhere in the system. :)
 #37645  by MZ per X
 27 Nov 2013, 23:13
Tracy Poff wrote:
Ultyzarus wrote:Publicly viewable, with saved screenshots of those sources.
Rather than archiving screenshots ourselves, I'd say we'd be better off working to have durable links to sources. In the case of web sites, a link to a copy of the site in the Wayback Machine is likely to be at least as durable as Oregami. If WebCite gets enough funding to carry on with its work, it would be a great tool for us as well.
Here, I disagree.

Static content delivery is cheap, and easily scaled, so I don't see why we should make Oregami dependent on other online ressources, as durable as they might be. Especially when it comes to sources, which are a very important part of our goals of transparency and scientific approach, but not very often downloaded at the same time, there's no good reason to send people somewhere else, I think.
Tracy Poff wrote:My guiding principle was that we should leverage the tools we're already building wherever possible. If screenshots of the game are useful as verification of details about the game, I don't think that it's unreasonable to store them right alongside the other screenshots. Perhaps someone will find them useful who wouldn't have encountered them if they'd been only in the source information section for the credits, or whatever. Similarly, if we're storing box scans anyway, and if a box scan is the source of some data, we might as well simply link to our copy of the box scan, rather than storing another copy.
While I can see the value in your suggestions, avoiding redundant data being the most important, I'd still vote for the source data being independent from any other data.

This independence will save us from quite some problems, the main problem being turning off people like Jotaro Raido who are only interested in a certain part of the data (credits in his case). The quality of source material for credits contributions doesn't need to be high, only the text needs to be readable, I once even used a camera to shoot Nintendo DS credits, or people use to paste dozens of credits screenshots together into a single one to better handle it. I see the danger that these contributors are then told to provide standard quality scans and shots for introduction into the covers or screenshots section of Oregami, then use the source link facility to save space, which would be counterproductive.

Furthermore, it could happen that covers or screenshots will need to be deleted for whatever reason, leaving us with unsourced data scattered throughout the database. In summary, I don't think that the added complexity of the data model for source links is worth its drawbacks.