Page MenuHomePhabricator

WikiBadge
Open, LowPublic

Description

At present there is no easy way to let other know and verify the contribution and participation in Wikimedia projects. The problem increases if someone is active in multiple projects. Endorsement and recolonization the skills or accomplishments of individual Wikipedians should be more standard.

Idea

Digital badges (Open Badges) will be provided upon the completion/participation in different ares of the Wikimedia movement. It will be similar as the 'Barnstars' but it will be more automated and will be build upon standard tools. A standalone tool will check and maintain the progress to get a new badge. It will also list all the badges of a wikipedian and s/he will be able to share them.

Goals & Scopes

The main goal of this tool will be to increase participation of new and existing wikipedians. I am ad administrator and founding member of Wikimedia Bangladesh Chapter. We initiated several programs to increase participation, attract and engage new contributors. From these programs and campaigns i have some observations i find increases the contribution, the list if flowing

  • A leader board/ competition (Example campaign: List of active wikipedians)
  • Short/ easy to achieve milestones (Example campaign: 5 new articles a week)
  • Recognition (Example campaign: Barnstars)
  • Stat (Example campaign: Article edit count)
  • (will add more... )

From these observations i thought it is good to have some standard tools which will encourage the Wikipedians. Then i posted the idea in the Bengali Wikipedia Village pump and got a big support (https://bn.wikipedia.org/wiki/WP:VP#Wikibadge). So i am planning to build a tool for the Bengali Wikipedia. If it is successful and other community is willing to use this tool then we will extend out plan, goals and scopes.

The Tool(s)

The Wiki Badge will be used as a single tool but it may use several other tools to perform successfully. Broadly the other tools could be following

  • A tool which determines when a certain user qualifies for a certain badge.
  • A tool which awards the badge itself

copied form the comment of @Lokal_Profil

Development plan

The overall development plan is to use/utilize the existing tools as much as possible. The final Wiki Badge tool could only call the other API and show the results. This final tool will be a standalone one. In the next phase this could be converted to a Mediawiki Extension or integrated in the Mediawiki core.

Notes:

Expected outcome at summit

I have the following expectation form the summit.

  • establish the scope and direction
  • finalize the list of existing tools which can be used with the Wiki Badge tool
  • get assistance from the analytics team
  • finalize the list of areas which will be used to award badges
  • discuss and finalize the development plan
  • get assistance from the experienced developers and develop a prototype at the end of the summit

Background

Event Timeline

Nasirkhan claimed this task.
Nasirkhan raised the priority of this task from to Needs Triage.
Nasirkhan updated the task description. (Show Details)
Nasirkhan subscribed.

Congratulations! This is one of the 52 proposals that made it through the first deadline of the Wikimedia-Developer-Summit-2016 selection process. Please pay attention to the next one: > By 6 Nov 2015, all Summit proposals must have active discussions and a Summit plan documented in the description. Proposals not reaching this critical mass can continue at their own path out of the Summit.

Lokal_Profil set Security to None.
Lokal_Profil subscribed.

What's the relation to the OpenBadges project?

That project (or at least the extension) makes it possible to issue badges from within MediaWiki itself. Similar to barnstars the communities can then set up and issue their own badges.

That extension does not however contain any of the mechanisms for detecting when a user has done X thus qualifying for a badge.

Meanwhile
https://mediawiki.org/wiki/OpenBadges (should) contain info and an analysis regarding the need for/use of OpenBadges for the Wikimedia movement (and translatewiki.net). Discussions regarding these also fit within the phabricator project.

There is no direct relation with the OpenBadges and there are some major differences with that. For example this tool will be a standalone one rather be an extension/core part of the Mediawiki. This tool will check and store the user contribution stat (if user wants to) and the badges the user received and about to receive. It also have an option to display the badges centrally. Along with this @Lokal_Profil also mentioned some points.

As this is proposed for Wikimedia-Developer-Summit-2016 I'm curious if there are already some architectural drafts for this tool that one could take a look at, or even code?

@Nasirkhan, this task is still missing clear Summit goals, topics that could be discussed here before, and active discussion. It would be good to sort out these problems before the next deadline on November 6.

There is no direct relation with the OpenBadges and there are some major differences with that. For example this tool will be a standalone one rather be an extension/core part of the Mediawiki. This tool will check and store the user contribution stat (if user wants to) and the badges the user received and about to receive. It also have an option to display the badges centrally. Along with this @Lokal_Profil also mentioned some points.

I would separate this into two bits.

  1. The tool which determines when a certain user qualifies for a certain badge.
  2. The tool which awards the badge itself (fulfilling the various OpenBadges standards etc.)

For no. 2 I would recommend using the existing OpenBadges-extension (not to say it doesn't need more work). If it was running on e.g. Meta then it could be used to award badges for any Wikimedia activity we would deem fit (since Meta is the closest thing to a universal home wiki for Wikimedia).

No. 1 I would see as less critical to have heavily integrated into MediaWiki. If it was an external tool it could then use an api call to the OpenBadges-extension to award the actual badge. If it is a MediaWiki-extension then I would hook it up to the OpenBadges-extension when it comes to the actual awarding of a badge.

In general I would say it makes sense separating the OpenBadges awarding code from whatever code determines Wikimedia specific awards.

As this is proposed for Wikimedia-Developer-Summit-2016 I'm curious if there are already some architectural drafts for this tool that one could take a look at, or even code?

The OpenBadges-extension is available through Vagrant.

As for the actual badges to award and what could be used to measure this the only thing I have are the discussions related to translatewiki here and here.


From the Dev Summits perspective the main things to find out are (IMHO):

  • Is there support for issuing these kind of badges from the WMF?
  • What should the structure look like (external tool + existing extension, two extensions, one new extension, part of core ...)
  • ...

I looked around a bit and Wikia has an Achievements extension which could be an inspiration for the "determine who qualifies for a badge" component.

edit:
Some info on what it does/doesn't do at Help:Achievements

November 6, and this proposal doesn't seem to have much traction, it is not on track. Unless there is a sudden change, I will leave the ultimate decision of pre-scheduling it for the Wikimedia-Developer-Summit-2016 to @RobLa-WMF and the Architecture Committee.

@Lokal_Profil thanks for your valuable comment and explanation.

First thing i want to clarify that, i am not against the Mediawiki extension nor integrating within the Mediawiki core. Rather i would love the see this implemented. But above all i would like to release a functional tool.

I want to use the existing tools as much as possible. For example to get the analytics report most of the time i use Super Counter (https://tools.wmflabs.org/supercount) and XTools (https://tools.wmflabs.org/xtools-ec). Even Wikimedia Statistics portal (http://stats.wikimedia.org/) is separate form the mediawiki installation. Along with this i used several other stats tools which are external tools.

At the very last of the comment @Lokal_Profil mentioned that if WMF have support to issue this type of badges and some other concerns. I updated the description of the task please read the sections and you may get a clear idea.

@Qgil can you please check the description and help me to move it to on track

@Qgil can you please check the description and help me to move it to on track

You may want to mention for clarity that you updated/expanded the task description in the meantime.

@Aklapper i am sorry, i should mention that i updated the description. Actually i mentioned this in an another issue and forgot to mention here.

Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open. If the session in this task took place, please make sure 1) that the session Etherpad notes are linked from this task, 2) that followup tasks for any actions identified have been created and linked from this task, 3) to change the status of this task to "resolved". If this session did not take place, change the task status to "declined". If this task itself has become a well-defined action which is not finished yet, drag and drop this task into the "Work continues after Summit" column on the project workboard. Thank you for your help!

Trying to collect the discussions me and @Nasirkhan had during the DevSummit:

For the badges to be successful the following key elements were identified:

  • It's important that the badge is found in a location with strong visual links to the project (i.e. if it is awarded for work on Swedish Wikipedia you should find it there, not on Meta).
  • The badge must be easy to share. I.e. there should be one url which takes you to the particular badge which you were awarded and want to share. From this point of view the current system with barnstars on talk pages works badly since these are archived or quickly becomes hard to find. Similarly a list of all your awarded badges (as currently implemented in Extension:OpenBadges) does not fulfill this need.
  • It must be possible to easily export your badge (in order to actually make it an Open Badge).

Two solutions (for issuing/displaying badges) which were discussed were Extension:OpenBadges and an alternative mechanism based on toollabs.

The Extension:OpenBadges-solution has the downside that it would require a new extension to be deployed on each wiki which wishes to implement this. Additionally it requires that the following issues be solved:

The tollabs based solution sidesteps many of the issues by handling the badge creating/issuing/processing/proofs on labs. When a badge is awarded this then creates a subpage in the users own name space which can be easily shared. This subpage contains a simple template which in turn contains the links to proofs etc. back on toollabs. The benefits are:

  • This allows a much richer system for handling badges (think codebits) while at the same time presenting an end product which looks as though it is part of the project on which the user is active.
  • Unique url to a badge (the particular user subpage e.g. User:Foo/Wikibadge/Bar
  • We would only need to maintain the code for triggering when a badge is issued and for the subpage creation, not that of any of the core Open Badge mechanics.
  • The tool could also support e.g. lists of most active contributors etc., something which is not supported through badges by themselves.

The downsides are that we would need to find a suitably licensed Open Source solution which can be deployed on toollabs. And in addition to what it already does it would have to support:

  • A way of externally triggering when a badge is deployed
  • Some hook which can be used to trigger the creation of the user subpage (on the correct wiki)

The above does not take into account what the Badges actually represent/what is being rewarded.

  • As a source of statistics supercount was identified as on of the more promising candidates since it supports getting stats through an API. It has the major drawback that it is not open source and so might disappear of toollabs.
  • As for what should be rewarded it would be interesting to get feedback from the Analytics team as to what they believe are the key point to reward an early contributor in order to make them stay on. Similarly it would be interesting to see what is most likely to keep active editors staying active over a longer time.

@Nasirkhan: Please add anything I missed or where you don't agree with my conclusion.

Worth tying into this discussion is the feedback in T124003

@Nasirkhan: Anything missing? What is the status of this task; is it blocked on anything? (Asking as you are set as task assignee here.)

@Nasirkhan: Anything missing? What is the status of this task; is it blocked on anything? (Asking as you are set as task assignee here.)

It is not blocked by any other issue. Rather it will need some additional codding assistance. At the time of of opening the issue it was planned to engage some additional resources.
I started to work on this project again hopefully i will be able to post some updates soon.

I started to work on this project again hopefully i will be able to post some updates soon.

Hi @Nasirkhan! This issue has been assigned to you a while ago. Could you please share a status update? Are you still working (or still plan to work) on this issue? Is there anything that others could help with? If you do not plan to work on this issue anymore, please remove yourself as assignee (via Add Action...Assign / Claim in the dropdown menu) so others could work on it. Thanks a lot!

@Nasirkhan: I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!).
Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task.
Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - it would be welcome! Thanks for your understanding!

@Aklapper thanks for looking into this project.
I am not working on this project right now. But may be work on it again.

Aklapper triaged this task as Low priority.Feb 10 2023, 12:09 PM