Talk:Community Tech/Tools for program and event organizers

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

For older discussions, see Talk:Community Tech/Tools for program and event organizers/Archive 1

Event tool feature ideas, August 2018[edit]

These are the open questions for event organizers from the August 9th update, copied from the project page. We'd love to have your thoughts!


Step 1: Organizer creates an event in the system (and Event page on wiki)[edit]

What types of information would you like to be able to report on?[edit]

  • channels used to promote the event
  • where and when the event took place
  • goals of the event (learning to edit a Wikipedia article, creating templates…)
  • how many people showed interest before the event (comment on some canal…)
  • how many people came
  • what people actually have been asking for and been actually informed about
  • whether there was something feeling as a lake: material, skill, connection problems…
  • after the event, did people seem to have assimilated the provided information

--Psychoslave (talk) 12:44, 11 August 2018 (UTC)

Hi @Psychoslave:, I want to make sure I understand: You want to put these items into the event record so you can run reports later? E.g., would you want to look and see whether you got more participants from Facebook or Meetup promotion? Something like that? And when you say "where the event took place," do you literally mean the venue? Or are you thinking in terms of wanting to report back to different "Event Partners," as I might call them? —JMatazzoni (WMF) (talk) 00:17, 14 August 2018 (UTC)
Yes, report them, and also being able to gather and analyze data to answer questions like "what communication canal seems the most efficient to attract people to a given kind of event in a given region?", so organizers have indicators how to prioritize their communication efforts. It's also important to have a ratio of people that showed interest and people that actually came to the event. For example we already went through thousands of like to a Facebook post regarding an event and only two people came to it. I think it's good to have event organizers being aware of that kind of gap, both for logistical and moral reasons.
And yes I meant literally where the venue took place, as I expect that the same communication methods/canals won't work with the same efficiency in different local contexts. So it's good to have the good picture of what works elsewhere, especially to grab whole new ideas or improve the way you are already communicating, but having specific local data that show some communication methods just doesn't work well in a given context is also very valuable. --Psychoslave (talk) 03:54, 14 August 2018 (UTC)
In case of using Facebook events, how many people were reached by the events. Maybe also how much effort was put into organizing the event; for example, how many trips to the venue, how many calls to the sponsors and so on.--Reem Al-Kashif (talk) 20:48, 11 August 2018 (UTC)
It is inaccurate at this stage to even thing about reporting data. The unique data which is otherwise unattainable is a list of participants. Collect this here, and with this information, any other computation can come from public datasets later. I do not want to distract this project from collecting a user list, but in the longer term, an alternative input will be any Wikimedia list like list of Wikipedia articles, category of photos, etc. The point here is to collect the list of items which will be the subject of computation in a later process. Blue Rasberry (talk) 13:29, 12 August 2018 (UTC)
I think the basic requirements of an event pages are: 1) information about the date, time, address, how to reach it (or how to connect if it is a remote event), program, what attendees need to do in advance or to take with them 2) list of participants 3) list of to-do during the event, such as list of articles to be written or reviewed. --Marta Arosio (WMIT) (talk) 08:42, 13 August 2018 (UTC)

How important a feature is automatic wiki page creation and updating to you?[edit]

  • Are you willing to accept a new and perhaps more standardized page design to get auto page creation?
  • Any help to streamline the report process is welcome, as long as it actually reduce the time which is required to provide this feedback and doesn't limit expression. That is, let a text field for free input. Actually, it would be great to even give an option for audio/video feedback. That would be in line with the integration of oral knowledge. If everybody in a room is fine with recording the event, it might also be great to record the whole event, as it would not only give access to its intrinsic pedagogic value, but also allow edithatons organizers to learn from each other by watching them. --Psychoslave (talk) 12:44, 11 August 2018 (UTC)
@Psychoslave Love that video feedback idea!--Reem Al-Kashif (talk) 20:51, 11 August 2018 (UTC)
  • What parts of the Event page change the most after creation so would benefit from automatic updating (e.g., the worklist?)? Is updating important to you?
  • I need a page but it does not need to look good. The user experience is similar to meetup.com - users need details on how to join the event but just as meetup.com is not the essential part of the experience of an event, the Wikimedia event page is not the essential part of a Wikimedia program or event. The point of the event page is only to communicate how to join the real event and also to collect the user account name in a signup process. Blue Rasberry (talk) 13:31, 12 August 2018 (UTC)
  • The page needs to be updated after creation, both with the participants that enroll in gradually and with the worklist, which often isn't complete from the beginning. --Marta Arosio (WMIT) (talk) 08:42, 13 August 2018 (UTC)

If participants’ usernames were in a database you could consult any time, would you still need to publish them on the Event page? Why?[edit]

Yes, to let people which were at the event contact each other through this list, without having to rely on a tiers availability. Of course that is in the case people agree to appear in this public list. Psychoslave (talk) 12:44, 11 August 2018 (UTC)
Yes, I think it encourages people to attend.--Reem Al-Kashif (talk) 20:53, 11 August 2018 (UTC)
No, in lots of programs people do not even know they are part of a cohort. The point of outreach is to get people to engage in a program, and not to get them to join a group. There are many reports to run with remixes of usernames. If a user joins one event then probably they go into 5-10 computations, and it makes no sense to assume that there will be an event page for each computation. Blue Rasberry (talk) 13:34, 12 August 2018 (UTC)
Well, I think both can be true. Maybe we need some different vocabulary to describe how connected the people are. Maybe "participant" for the disconnected, "cohort" for those who attend at the same place/time, and "team" where people perceive they are working together on the task (which might be as a cohort or not). For example, I would describe my 1lib1ref group as a "team" (they were working together to achieve a particular goal). I think "teams" are interesting because you have league tables for teams and a bit of friendly competition among teams can be good for getting a lot done :-) I don't say we need league tables in the first version but it's where I'd like to see this go longer term.
I think the main requirement is to have the participants' list somewhere; to have it in the event page is not strictly necessary, but it would be better in order to have all the information in the same place and to commit people more. --Marta Arosio (WMIT) (talk) 08:42, 13 August 2018 (UTC)
Not necessarily. I think it would actually be helpful to have the option to not publicize all participants, because some people do not consent for their participation in an event to be public (but they might be fine with including their edits in aggregate reporting). Rachel Helps (BYU) (talk) 17:49, 13 August 2018 (UTC)
Agreed that having options here is nice, but the current Dashboard lists all the participants and I haven't had an issue with anyone being bothered by this, so I think that could be "version 1". Kerry Raymond (talk) 07:28, 14 August 2018 (UTC)

Other comments or suggestions for Step 1?[edit]

Avoid acronym
A first tiny feedback: if possible, let's avoid to introduce yet an other acronym. Event-tool(s) is not that long, and it keep the topic clear for anyone, which to my mind is good for staying as open and welcoming as we can. --Psychoslave (talk) 12:17, 11 August 2018 (UTC)
Agreed. Acronyms also don't translate well in some languages (including Arabic).--Reem Al-Kashif (talk) 20:44, 11 August 2018 (UTC)
Good point. The original working title for this was "Editathon Tool," which is hard both to write and to say! But Event Tool is easier in all ways. Thanks for the reminder. JMatazzoni (WMF) (talk) 23:04, 13 August 2018 (UTC)
Treatment of personal data
Regarding For organizers only, we legally have to inform and obtain consent of people if we do keep some personal data. So reading event participants will not see or use the ET, it's not clear whether this was taken into account: each participant should have possibility to access data related to its own person, although the whole gathered data sets should not be accessible to every participant. Whatever the tools enable to collect and cross-process, the processes and resulting publication should conform to law like General Data Protection Regulation. --Psychoslave (talk) 12:17, 11 August 2018 (UTC)
Hi @Psychoslave:. In saying this tool is "for organizers only," I was trying to respond to input I've had from many organizers, who want to keep event participants focused on the wiki rather than on a a separate tool. So it was more an expression of a design principle for the project. Sorry if the remark wasn't clear. You're right, though, to observe that there are many privacy issues we'll need to work out if we build everything described. —JMatazzoni (WMF) (talk) 23:04, 13 August 2018 (UTC)

Step 2: Participant sign-up[edit]

If we offer only a standard signup form (at first), would that work for you? What would a standard form need to include?[edit]

  • As a result, organiser should be able to know:
    • how many people intend to come
    • a point contact for each of interested people
  • Nice to have would be:
    • pointing people to pertaining documentation regarding the event, for example to give specific instruction what participant can prepare to take out the most of the event (example, create Wikipedia account if they want wish, before the event)
    • specific questions attendees might have

Psychoslave (talk) 12:56, 11 August 2018 (UTC)

Name, phone number (if possible), email, what questions do people hope to get answers for in the event, how much do they know about Wikipedia.--Reem Al-Kashif (talk) 20:58, 11 August 2018 (UTC)
I need nothing except a sign up button and a shortcut URL. The event is the attraction not the event page. I want participants off the event page and engaged in the event as soon as possible. Blue Rasberry (talk) 13:35, 12 August 2018 (UTC)
I would love to have a simple standard signup form. I would like to have the nickname/name, a contact (talk page is fine, as long as they have it, if not something else), the organization they work for (if it is GLAM event), maybe the level of knowledge of Wiki projects.
Speaking of participants, it would be nice to have the chance to flag if they were actually present to the event or just registered and never popped up and a way to monitor their activity after the event (one of the main points of the event is if they are actually useful to engage people in the medium term or not). --Marta Arosio (WMIT) (talk) 08:58, 13 August 2018 (UTC)

If we can offer a tool that lets you select from a predefined set of signup form options, what would you need it to offer?[edit]

  • e.g., questions about gender or age, a requirement to approve a safe-space policy...?
  • Be selective: the simpler this tool is, the more likely it is to get built.
I would like to have question about gender, age, level of studies, kind of organization they work in, level of knowledge of wiki projects and where they live (I think about online events also). All answers can be optional, in order not to scare people away. --Marta Arosio (WMIT) (talk) 08:58, 13 August 2018 (UTC)

In particular, should a checkbox for email-list opt in be standard or optional?[edit]

Standard! --Marta Arosio (WMIT) (talk) 08:58, 13 August 2018 (UTC)
Standard! If you need to change any previously advertised arrangements ("we will be in room 405 instead of 306"), you need a way to communicate efficiently with those who may have signed up with the old information. You need a way to remind them a day or so in advance that the event is on and remind them what to bring etc. Also after the event, most newbies won't know how to "Talk" or won't feel comfortable to use it. They prefer email and other more familiar means of communication, plus most of them forget their password so the account needs to have an email address so they can do password reset. Kerry Raymond (talk) 07:33, 14 August 2018 (UTC)

Other comments or suggestions for Step 2?[edit]

Step 3: Wiki account creation[edit]

What do you think about the Proposed solutions/feature ideas?[edit]

  • The issue here is that that Wiki blocks more than 6 account registrations at one IP address in one day. All available pathways to address this have high failure rates. This is a devastating problem because when a group of people organize an event, and they have sponsors, and they recruit a lot of people to be in the room, then if Wiki administration then prohibits account registration for the participants then the result is devastating. Having an on-wiki admin shut down an event, when they themselves do not do events, is demoralizing, wastes huge amounts of money, greatly disrupts the relationship with the sponsor, and gives a horrible new user experience for coming to a wiki event when they cannot participate.
The horrible tension remains in place! There is no wiki-legal process for organizing events in the way that typical event organizers would find natural and workable! The current process in place requires the breaking of many wiki rules! There are multiple rules sets in place and they conflict with each other. The process either needs mediation or a tool.
There is a desired tool. It is discussed in en:Wikipedia:Event coordinator and elsewhere from the discussion archives. The takeaway is that instead of granting advanced userrights for a trusted user to be "event coordinator", then instead there could be a bot on an event page which creates accounts for new users. The current process is that new users at events get their wiki accounts from someone with a userright. The new proposed process is that no human gets an advanced userright, but instead the new users who register on an event page get publicly logged as part of a cohort and are easy to observe if only the event page publicly reports who they are. Also, their user account registration should log them as being part of a program or event, and the program itself should have a record of the organizer in charge who can take blame. Blue Rasberry (talk) 13:48, 12 August 2018 (UTC)
I think that all three proposals are great, and that they would really help the organization. --Marta Arosio (WMIT) (talk) 09:12, 13 August 2018 (UTC)
I agree with Blue Rasberry's comments above. Account creation is one of the biggest timewasters in my (admittedly small) experience with events. The new "event planner" user right helps, so I don't have to request having the add user user right each time, but I still need an extra person to help with account creation, and participants end up logging in twice (one through my account creator special page and once back on their own computer) with our current setup. Rachel Helps (BYU) (talk) 17:53, 13 August 2018 (UTC)
At the moment, I ask people to sign up in advance, which means a lot will come having already done that. I tell people to sign up on their phones having turned off their Wifi (which means they aren't all coming in on the same IP address) which deals with the more tech-savvy in the room (not everyone knows how to turn off their Wifi it seems). Some can also signup on other language Wikipedias (if they are multi-lingual) or on Simple English Wikipedia or Commons or other sister projects (if monolingually English-speaking). And I mop up the rest with my account creator right. OK, this stuff will work, but I would still like it to be easier. One of the things you can do is pre-register your event with its IP address and you can make the 6-account restriction go away. But in practice, I am rarely in a venue that I know well, usually it is organised by a partner organisation and the individual I deal with will not know the IP address and my request to find out will disappear into their Bynzantine labyrinth of tech support who won't understand why I need to know ("just turn on your Wifi and choose OurPublicWifi" is the kind of unhelpful response I get). So, that method is a loser. But, why can't I pre-register the event and be given a password and then, on the day within the time frames pre-registered for the event, I invoke something (lets call it GameOn), supply the eventname and password and the IP address I am using at that point in time becomes free of the limit for the duration of the pre-registered event. Why can't that work? The only difference to the existing mechanism is that the IP address is only known at event time not in advance. Kerry Raymond (talk) 07:52, 14 August 2018 (UTC)
That's an interesting idea @Kerry Raymond:. I will have the team look into it. It's clear this is an area that is not working as it should. Thanks. JMatazzoni (WMF) (talk) 18:47, 14 August 2018 (UTC)

Other comments or suggestions for Step 3?[edit]

Step 4: Participants check-in[edit]

What do you think about the Proposed solutions/feature ideas?[edit]

  • People at the event should be able to input themselves into this roster class (or obviously before they come), if they wish to. That way organizers just have to give the URL at the start of the event, and those who want can fill the corresponding form, far easier and efficient. Organizers might have a different form to enter lists, but more importantly to give a separate count of how many people joined the event, giving either an exact or approximate answer. --Psychoslave (talk) 13:10, 11 August 2018 (UTC)
  • The problem with in-person check in is the account limit discussed in part #3. There can be a 6-person limit for account registration. For events with fewer than 30 people it is easy for organizers to count number of registered and talk in person to participants to see that they have registered. If only the problem of #3 can be solved and all participants can get registered then otherwise day of registration is easy. Blue Rasberry (talk) 13:39, 12 August 2018 (UTC)
  • Class Roster, with both the chance to check if previously registered people did actually show up and to enroll new people, sounds fine. It would be nice if there was a chance to monitor all the contributions of the attendees in a certain time (the time of the event but also the days and weeks after, especially for newbies, in order to check if they were actually committed). --Marta Arosio (WMIT) (talk) 09:18, 13 August 2018 (UTC)
  • I'm not sure if it's required in the US, but I like to get consent before tracking participants through their username. It takes a long time for participants to type in a specific URL, so I usually use a paper sign-up (it also procrastinates the input until after the event, when I have more time to sit and type something). It would be ideal if participants could sign in through a link on their own talk page--maybe that's something I could change about my editing event workflow? I really don't know a good way to solve this problem. Rachel Helps (BYU) (talk) 18:01, 13 August 2018 (UTC)
  • I generally explain that all contributions to Wikipedia are visible to everyone and are linked back to their account. I think a consent process might mislead people into thinking they can contribute in a private way that they cannot. In practice, if I find that I don't have a list of the user names, you can often figure out the user names if you know the articles being worked on (e.g. if you have supplied a list) or the category they are in. If they are employees of an organisation, you have to do the paid contribution declaration on the user page, so you can search for that. There are lots of ways for the cunning-as-a-rat event coordinator to collect the user names even if they aren't freely given. In practice most people happily give them to me so I am mainly concerned with tracking down ones written in undecipherable handwriting (e.g. my own) or because user names are case-sensitive. I don't tend to bother with arrival processes beyond login/sign-up to Wikipedia because usually the time for the event is quite short and I can't waste time with people filling in forms. Better to do any form filling as part of signing up in advance to the event, as my events don't have a need to maintain an attendance register (there's neither reward nor punishment for attending or not). Kerry Raymond (talk) 08:10, 14 August 2018 (UTC)

Other comments or suggestions for Step 4?[edit]

API for getting official Grant Metrics stats for Dashboard events / campaigns[edit]

Hey User:TBolliger (WMF)! Following up from WMCON, and in the spirit of this wishlist request and the 'suite of tools' vision you have for event organizer support, I wanted to put adding an API for getting Grant Metrics stats back on your radar. That would allow me to build a feature into the Dashboard so that users can easily get the official Grant Metrics stats according to whatever the latest definitions of global metrics and such are, without having to do extra data management. Beyond improvements to the Dashboard itself, that would be the most helpful thing I can think of to better support the people who voted for this.--Sage (Wiki Ed) (talk) 21:51, 14 May 2018 (UTC)

User:DannyH (WMF), User:JMatazzoni (WMF): I'm restoring this from the archive, since it may have fallen through the cracks with the handoff from Trevor. If a lot of the focus will be on extensions to Grant Metrics, then adding a way for the Dashboard to talk to Grant Metrics would be really helpful for the programs that have already gone pretty far down the road with developing their program processes around the Dashboard. (I'm thinking especially of Art+Feminism and Wikimedia NYC, which both now run a lot of edit-a-thons through the Dashboard, but could benefit from easy access to the evolving metrics capabilities of Grant Metrics.)
Joe, I'd also love to talk with you — perhaps after this round of consultation with editathon organizers — about what you learn around participant sign-up and account creation. As you know, the Dashboard has features for these things now, but we've mainly built them and iterated on them around the needs of the Art+Feminism workflow, and I'd like to find out where that breaks down for other organizers whom I've had less contact with.--Sage (Wiki Ed) (talk) 18:54, 10 August 2018 (UTC)
There seems to be a presumption that participants aren't interested in metrics. Some of my groups are very keen to see the Dashboard. They want to see their stats at the end of the session (but of course the Dashboard takes a while to update which is always a disappointment to them). Obviously my ideal would be real-time (or very near real-time) stats, but more realistically could we send out an email to the participants with a link to the Dashboard once the Dashboard should have been update to capture the event/session. And, because that article view figure just grows and grows and grows, follow-up say once a month with "wow, 1.04M page views of the articles you updated during Event Name". It might be nice to put the dashboard links for the participants onto their User page. Kerry Raymond (talk) 08:29, 14 August 2018 (UTC)

Comments from bluerasberry[edit]

There is a call for answers to questions in the section "Event tool feature ideas, August 2018" but I want to summarize a desired workflow here.

First everything in the August update is what I want to see. All of it is correct and none of it is incorrect. I explain things in my own way here but I think the progress is right.

I want to emphasize my agreement with @Sage (Wiki Ed): The correct development process is the one that anticipates current and future third-party development. The data needs for event reporting are diverse and different stakeholders will want different reports. There are endless variations on potential reports. Reports will differ for the WMF grants team, Wikimedia chapters, universities, GLAM institutes, STEM institutes, government organizations, and web traffic analysts.

What Sage and I both want is for an early data export function in the tool, through an API now or eventually, so that various dashboards can access key data. The most relevant dataset which Wikimedia projects are not exporting is "Wikimedia users in a cohort". Wikimedia does not export this because we do not even compile this list in Wikimedia projects. Meetup.com, Facebook, etc have processes by means of which individuals can click a button to join a group. I want an on-wiki process for anyone to click to join a group. From that point, the dataset / list of who is in the group is available for export into the subsequent processing of custom tweaking and then from there to any platform's visualization.

Although I am asking for a "click to join event" button in Wikimedia projects which can export to outside projects what I really want in the longer term is this kind of process:

1. build list

  • participant can "click to join" from a Wikimedia project page
  • organizer can add
  • alternative ways, like add any list, or who is in a wikiproject, or everyone who edited an article
  • human choice compiles list

2. import / export stage

  • make list from #1 available to 3rd party
  • also allow any 3rd party to input lists here to go into WMF computation

3. computation on list

  • typically only organizers will want to see this
  • wide variation in need
  • WMF wants user data, does not care about media topic
  • partners want topic data, do not care about users

4. report of computation

  • WMF grants report is the present urgency
  • orgs which fund wiki want a different report




Blue Rasberry (talk) 13:25, 12 August 2018 (UTC)