Talk:Community Tech/Programs & Events Dashboard
Discussion about the Community Tech team's work on the Programs & Events Dashboard.
Multiwiki support
editI agree, multiwiki is dead. Long live multiwiki! The idea was that * a user or assignment might be from any wiki, and * every course might include articles from several wikis. This is mostly implemented by now, but comes back into play as we tighten up the analytics. Adamw (talk) 15:29, 12 July 2016 (UTC)
- Yeah, the articles part is done. I think the piece that's left is letting the participant pick a home wiki. -- DannyH (WMF) (talk) 20:27, 12 July 2016 (UTC)
Bluerasberry's review
editI wish to share some thoughts on some of the markups for development of this tool. To help with discussion, I made user documentation for this tool at Programs & Events Dashboard.
This campaign programs tab concept is great. In the previous Education Program Extension, there was a feature for grouping classes together in a system like "categories" in Wikimedia projects. This function was not present in the Wiki Ed dashboard, and some people have missed it. Like for example, people have wanted to browse programs in their area.
The markup here is imagining that "Year of Science" is a campaign in the tool for en:Wikipedia:Year of Science events. That is great; this kind of function needs to exist. However, there needs to be a way to group individual programs in multiple sets, and while some of those sets will be "campaigns", some will not. For example, year of science is its own campaign, but individual programs in year of science also need to be grouped in other campaigns like "women scientists campaign" and other non-campaign groups like "wiki events at academic conferences", "wiki events in New York", "wiki events supported by (local chapter)", and "wiki events in the United States". While the output of this report is great, if the group is "Wiki events in the United States" then "campaign" does not seem like the right term for this. A correct term could be "category", and include the campaign concept, but the tool is needed for more than just campaigns.
I question the usefulness of some features campaign overview tab page. This main function of the page shown in this markup is for a campaign organizer to invite a program organizer to create an instance of an event page and automatically tag it as being part of a campaign. That function is necessary. The part that I feel is less useful is the prompting for the campaign organizer to describe the campaign in the tool, and for the local program organizer to accept the campaign manager's text in the tool. I confirm that the campaign must be described in text, and that program organizers need their event pages pre-populated with a text description from the campaign. The part that seems problematic is the management of the text in the dashboard rather than on-wiki. The dashboard's word processor is difficult to manage and also it is an anti-wiki practice to put the management of text in one's person's control. Engagement in the dashboard competes with engagement on-wiki, so that is an anti-wiki practice also. It is already established that Wikipedians like editing meetup pages and do so often, but with this dashboard, only people with advanced userrights will be able to change the text of events, provide links to support, or do the routine things that experienced wiki event participants do to help newcomers. My wish is that the dashboard could primarily be used for event registration and tracking, and only minimally as a place to develop event descriptions and support materials. Every instance of a dashboard program should be complemented with its own on-wiki program page that anyone can edit in the routine wiki way. Perhaps registering for a campaign can result in the one-time setup of an on-wiki program page which provides a link to dashboard registration and some text for the event from the dashboard, and thereafter, participants engage with the on-wiki page and not the dashboard. A range of problems arises when the wiki community loses the ability to communicate with a program on-wiki.
Definitely there should be a "create a program" tool as depicted here. One problem with the tool as depicted is the start and end time. The Wikimedia Foundation and the Wikimedia community are not in alignment with each other about expectations of event start and stop times. I propose to leave start and stop times off the "program creation" tool, and instead make time ranges part of the process for collecting metrics reports after the fact.
Historically, many Wikimedia Foundation staff have imagined that wiki outreach events are contained in a scheduled experience, like for example, a 3 hour workshop. They have asked for the outcomes of that workshop in the scheduled time. In contrast, the Wikimedia community is more likely to engage with program participants over a longer period of time. For example, people might attend a workshop, then within a week in their free time they may contribute more to Wikipedia now that they have had workshop training. In that case, the time period of interest might be the workshop and a week after, and not only the day of the workshop. The dashboard also collects information on article pageviews, which historically has not been a Wikimedia Foundation concern. Pageviews are the priority for practically every stakeholder organization outside the WMF, like all GLAM organizations, STEM organizations, and almost every institution that would have staff Wikipedia program organizers. The problem with dates and pageviews is that if someone sets a short daterange, then that can impair the collection of pageview reports of outcomes for events when 3-month, annual, or multi-year reports are needed. Practically every GLAM and STEM organization which uses this tool is going to want multi-year data. Because I see the date field here, I recognize that the expectation is collecting 1-day data for WMF interests or 6-week data for classroom interest. Actually, Wikimedia chapters and partners have a different need that is complex enough to come into continual conflict with anyone who puts in dates without understanding how data will be used.
Blue Rasberry (talk) 16:21, 19 August 2016 (UTC)
- Hi, thanks for your thoughts. For the categories idea, it sounds like what you want is a way to search based on structured metadata -- location (New York, or USA), sponsorship (local chapters), context (academic conferences). That's definitely possible, but it's a pretty big feature request -- the dashboard isn't currently capturing this information as metadata. Who do you think would be using that feature? Would someone be looking for events in New York because they live in the area and want to find events to participate in? Or is there some other reason why someone would want to keep track of New York programs?
- For the campaign text: Thanks for pointing out the importance of the on-wiki event pages. If there's an on-wiki page, we should definitely be featuring that link prominently. As an example, this program page for the Schomburg Black Life Matters Editathon encourages people to sign in, and then go back to the event page on Wikipedia. They shouldn't have to do special formatting to make that link big and prominent, it should already be a part of the interface.
- But some programs may not need an on-wiki page. This page for the MolES Edit-a-thon has some simple welcome text and a description of what they're planning to do. I don't think it would make sense for that group to create a separate on-wiki page for that information; it's just extra work for them.
- About the date and time picker: It sounds like there's two different things that you're interested in capturing -- the dates of the actual event, and then some time after the event when you want to measure the impact of the event. Is that right? -- DannyH (WMF) (talk) 23:55, 19 August 2016 (UTC)
- DannyH (WMF) Sorry for the late reply - I missed your message and only took note during a 8 September phone call with Amanda Bittaker and others.
- About categories: You called this a "search based on structured metadata" and said that it is a big feature request. I am looking for something, and a category system would work, but if it is complicated, then let me try to make the same request in a different way. I have difficulty saying what I need, and it is really difficult for me to suggest anything about software development, but if something would serve my purpose then I would recognize it. What I need is a way to aggregate multiple instances of P&E reports into one super report. Perhaps you know the Labs tool PagePile. I think this is like a category system, because a person can make their own list of Wikipedia articles, and I feel that any list is like a category. Once they have a "pagepile" list, then they can process all the items in that list with a tool. Would it be possible to make something like that for the P&E Dashboard? Could a person make a "pagepile" of individual dashboard events, then aggregate them into a sum report in another instance of the dashboard which reports the sum of participants, the sum of edits, the sum of articles, and so on? If that is possible, then that would meet my need. You noted that Black Lives Matter event. It would be desireable to automatically sum the outcomes of every Black Lives Matter event, in addition to being able to see their individual reports in the dashboard.
- Stay in touch about best practices for event pages, whether on-wiki or in this dashboard system. Honestly, I regret sending new users to the dashboard to sign in because it exposes them to an interface that is of no use to them, and which event organizers cannot easily manipulate. Whatever the case, be aware that the norm for Wikimedia community groups (chapters or anything else) is to do no event documentation whatsoever. Most events happen without a record of the event happening. Among events that are documented, various groups use English Wikipedia, Meta-Wiki, their own non-WMF wiki, services like Eventbrite, private event websites, Facebook, and email forms. There is no standard or common thread among establishing Wikimedia events. If I had my way, this P&E dashboard would be the common feature, and wherever else participants registered they would register here also as the official tool which generate the official data and record of the event.
- About the date and time picker - I would prefer that the tool start collecting data when any instance of the dashboard is set up, and then by default never stop updating reports after that. I think that is what it does already. If there were additional development of this, then I wish that it would ask for confirmation of the tracking start date, then offer some suggested reporting options, like 1-day outcomes, 1 week, 1 month, then 3-month and 1 year reports. Beyond that it could ask for a custom range. There is wide confusion in the Wikimedia community about how events should be reported, and whether a 3-hour event should have a report only for what happens in those 3 hours, or whether it is okay to report what happens when attendees go home and edit more. Personally, I would advocate that anyone inspired to edit in the next few days should be included in event outcomes. There are a lot of current problems with managing the times in the dashboard, and reports can turn really strange. We could talk more about that when it becomes necessary. Thanks. Blue Rasberry (talk) 18:26, 13 September 2016 (UTC)
- Bluerasberry I think for now, we'll be doing roll-up stats at the Campaign level. So you'll be able to see stats for all Black Lives Matter events, if they're all connected to the Black Lives Matter campaign. It's possible that we could come up with an additional layer of categories to split the data in different ways, but we need to build the Campaign/Program features first, and then we'll see what the level of need is for putting the data together in different ways. -- DannyH (WMF) (talk) 23:27, 13 September 2016 (UTC)