Additional comments from the Committee:
- This is an encyclopedia, not a game. That said, I am a big fan of games. Big. Fan. Of Games. I have often said that Wikipedia is, in fact, a game. And I really really liked the speech by Raph Koster at Wikimania London. However, I am against making games randomly for the sake of the technology that can do it. It's better to start with a game that answers a specific need and then develop the software to build it (such as Magnus' gender game, which has enabled us to add gender to most biography items on Wikidata).
- Gamification is an under-explored approach to increasing participation, and effective research and exploration in this area has significant potential for impact. However, the proposal does not present a credible plan for building a gamification tool.
- I have a hard time deciding where this project fits (and if it fits with a strategic priority). In theory an ORES-like tool for gamification could be used by others to develop programs that increase volunteer retention and engagement. However, I find it the lack of endorsements of this proposal troubling. I also am not sure that the absence of a gamification service is the reason why gamification initiatives have failed to develop/materialize over the years.
- Wikipedia as a game is a real need.
- On principle, gamification is great: it can be a great way to bring in new users who have fun and can join a community. However, I'm not so sure the current proposal works well for that.
- Our knowledge base is so large which can be offered as encyclopaedia gaming as a service! It's a great thing with potential impact on branding, engagement and many possibilities. If a nice presentation of data can be present by API, it's a nice to have. A game engine, well, I am doubtful how general could it be. Moreover, unfortunately it may not fit into WMF's radar. Personally, I do think it can open up an opportunity for younger generations.
- I suppose the software would allow metrics for usage.
- The proposal does not include well-defined quantitative or qualitative measures of success.
- Assuming the software is developed by the end of the project, I think there is still risk that the service won't be adopted/used by others. I'm also not sure whether it's possible to develop one service that can be general enough to meet the needs/paramaters of other projects or be adopted by others who want to build new games.
- I demand a better API from MediaWiki. I curse the old ugly XML. Gaming engine builds upon on old API. It's unclear whether it helps with getting data from Wiki or providing a place for other applications to use. How many databases are possibility open and synced by WMF? How can documentation can be found? It’s an even bigger problem. A new engine wouldn't help because it's another The Emperor's New Clothes story to our old MediaWiki. Besides, an engine wouldn't be enough for the great many of needs for application developers. I can imagine they would still need to access Wiki API anyhow.
- Probably doable, though the breakdown in activities is unclear at best.
- The proposal does not present a credible implementation plan or timeline, and the proposed team appears to have little or no experience with gamification.
- The scope seems very large: can the grantees conduct a community consultation about criteria/parameters for a central service, develop the software, and build and test it in 6 months? The grantees do however, seem to have relevant experience in software development and gamification.
- I'm unsure what the actual deliverable of this setup is - it seems very vague. I would suggest having: 1) specific games targeting specific communities, 2) reasons why they are difficult to capture with Distributed Wikidata Game, 3) Why this project would do better than (2), 4) Commitment to actually building (1)
- It's doable considering the experience of veterans. With the huge amount of time investment, I won't doubt there will be a prototype. The concern I have in the proposal is that it doesn't have anything related to technical fundamentals. Speaking in terms of a level of game engine (backend service), I think that must be included.
- There is little community involvement--perhaps because the applicant needs to start with the need that a game addresses, then state the game, then development, not the other way around.
- I'm worried mostly about impact + sustainability. This seems to describe a framework for gamified services, but not actual games. This makes it really hard to track actual deliverables. No particular games or communities have been identified either, which doesn’t inspire confidence. The highly successful Wikidata Game, nor the similar 'Gamification Engine' Distributed Wikidata game have been mentioned.
- It only helps enabling possible diversity of many games. But it generally does not fit to a community. At least, who will run the demo program? Who will operate the hardware and software env?
- Nice idea (the best in the last rounds!), but the applicants do not have a clear impact after the grant ends, and they do not know how they can measure the success of the project. The budget has a medium risk so I will remain Neutral.
- There are some key differences between ORES and this proposal. The ORES was intended to address a major problem of critical wiki-work and an identified need by the community; it also had tons of community support and WMF staff backing. In my opinion, the case for a gamification service has yet to be made.
- I like the idea and mainly the API solution but I don't understand the 70 days of development. It needs an expert's evaluation.
- Good idea, but poor execution in this phase would not be a good sign.
- Personally, it's a great idea to me. But the approach does not address the initial problems. Solving old problems by opening a new problem standing on old problems--it’s difficult.
- We already have Wiki labels for this. I would prefer to see more development put into that instead.
|
wikimedia · org .
