Wikimedia Meta-Wiki

Community Tech/Grant metrics tool/Archive

< Community Tech | Grant metrics tool

Old specifications

edit

Main page

edit
 
Main page wireframe
  • The entry point to the tool will be linked from the Proposal hub page (example) as well as Reporting requirements and other help pages.
  • The tool will be on Tool Labs.
  • Main page of the tool: the grantee logs in (using OAUTH).
  • After login, grantee sees the list of grants/projects that they created or have permission to view/edit.
  • Clicking on a project name takes the grantee to that project's Report page.

Project page

edit
 
Project page wireframe
  • On the Project page, the grantee can create a new event -- this could be a single-day editathon or a long-term initiative, whatever the grantee needs to track.
  • The grantee will come up with a name for each event. The name is a phrase that helps program organizers tell the events apart -- February vs October, Chicago vs NYC.
  • The Project page lists the events in the grantee's project, in a table that displays the current stats for that event: Participants, New editors, 30 day retention, Pages created, Pages improved (as defined above). The table has a line at the top for the total stats so far.
  • The grantee can click on the row for an event to go to that Event page.
  • Also from the Project page: the grantee can add more usernames as organizers, so that they can access and update the event data.

Event page

edit
 
Event page wireframe
 
Event page - History modal wireframe

The goal of this page is to define the set of revisions that the metrics calculation will be based on. There are many ways to define that set. We'll probably start with a limited number of ways to define the revisions, and then add more options when we've seen how the basic version works.

  • The Event page has fields to enter in the following information:
    • Usernames - usernames of participants in the event. (This could be generated automatically from a hashtag)
    • Pages - the target content pages for the event, expressed as a list of pages, categories, hashtags, talk page templates, or any page
    • Wiki(s) - the target wiki(s), or all wikis
    • Time period - could be start and end dates, or starting from here on
  • The grantee can save new data, and see the total stats by clicking "Update totals".
  • If a grantee makes a mistake and deletes data from one of the boxes, they can revert to a previous version using a history/revision modal.

Questions to early reviewers

edit

This is a short list of questions we're asking early-stage reviewers. Answer to these questions help inform the creation of the wireframes and tool specifications.

  • Would this tool meet your needs for tracking the grant metrics relevant to your projects?
  • What works, what's missing?
    • Does this tool increase/reduce the amount of work you currently do to collect metrics? Does it sound easy to use?
  • Entry point -- how would you want to get there? Where do you find it?
  • For your projects:
    • Who needs access? Should people have different levels of permissions (e.g. editing vs viewing)?
    • Do you use multiple ways of tracking content added/edited? E.g. wiki project pages + categories? hashtags + talk page templates? etc.
    • For new editor retention: do you want a single, set time period for calculating retention (e.g. 30 days after), multiple time periods (e.g. 1, 3, 6, 12 months after), or customizable time periods (e.g. 45 days or 62 days after)?
  • Output -- what would be helpful? Wikitext table, csv file, just copy the numbers into your report?
  • Do you use the Programs and Events Dashboard? Would this tool duplicate functionality that you already get from the Dashboard?
  • Do you use hashtags? Should hashtags be supported by this tool?

Details to figure out later

edit

These are questions that we'll figure out after the wireframe phase, when we're sure that we're going in the right direction.

  • How do you create a new project profile? Created by individual? If an individual leaves the chapter, how does ownership transfer?
  • For series of events, should parameters be auto-populated? (e.g. same usernames, wiki pages, etc.)
  • How to add more organizers? Can you remove organizers? (Can't remove the original ones?)
  • Permissions -- do we need editing vs viewing?
  • We could give staff access/editing rights in order to help out when there's a problem. Are people comfortable with staff having admin rights?
  • How do you create/delete/update an Event?
  • Events page - how do you update the name of the event?
  • History/revision modal: Swapping to the old version -- what does the modal look like?

Meeting notes

edit

May 1, 2017

edit

Danny & Sati meeting to go over feedback from the user sessions at WikiCon.

The most common use case that came up was people using categories, project pages and templates to generate the list of editors/edits, rather than starting with a list of editors. Sometimes the categories are project-specific, eg "Articles used in X Program", which would exclude irrelevant pages.

So -- instead of forcing the input into the boxes "Editors" and "Pages", we ask for whatever input they have, maybe chosen by dropdown. The only thing that matters is whether this leads to results that make sense. Think of it like an advanced search -- you're narrowing down from every edit ever to only include the relevant edits. How you do that doesn't matter, as long as you end up with the correct set of edits to start counting.

So maybe we do it as a search, and show a "preview", as Gmail does when you're creating a filter. Take the info provided, and show a log of the edits that fit those requirements. If that's not the edits that you're looking for (because it's too broad, or too narrow, or you put in incorrect info), then that's your cue to refine the search differently. Once you have the correct set of information in that log, you can run the numbers based on that.

That would help people feel confident about the numbers -- if the numbers seem off, this is your way to check where the mistake is.

You should be able to see and export the input, the raw log (preview) and the output (the actual count). The log could be exported as a csv?

Plan for the next few steps:

  • New wireframe and specs, Trevor can help
  • Kickoff with team and Sati, to get suggestions/feasibility from team
  • Show updated wireframes/specs to larger programs/grants community, get input
  • Start making it.

May 20, 2017

edit

Niharika and Danny briefly chat at the Hackathon.

  • How about we have tags for events instead of dealing with the complications that come with having programs?
    • Every event is individual, can be created in isolation.
    • Events have associated tags (with a bunch of predefined tags (can also be custom defined for specific use-cases)). Like 'hackathon', 'editathon' etc.
    • Each event can have a few authorized editors/reviewers who have edit capability for the event.
    • Ability to clone events to avoid filling in same things all over.
    • Makes architectural decisions easier and the tool simpler.
  • Look at https://metrics.wmflabs.org/ - work off of it?

Open questions

edit
  • New registrants -- definition? Sati says username created within 2 weeks of program beginning. Possible to use <5 edits instead?
  • 30 days retention -- something that could be recalculated any time, as more people return and edit. Use a recalculate button. Add a way to show how many days it's been since the end of the program. (Put a "x days ago" under the End time.)
  • 14 days or 30 days retention? 30 seems harsh.
  • Add a way to clone a previous event? So you could import the participants/pages data already entered.
  • Discoverable main page? Only organizers can add/edit data fields, but anyone can view
  • Can we build this on-wiki?
edit

Annual Plan grants

edit

Project grants

edit
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Tech/Grant_metrics_tool/Archive&oldid=16899001"