On Tuesday Mo (Máirín Duffy) and I did affinity mapping using realtimeboard.com (this is a well-designed tool for remote whiteboarding), the end results of you can see here . We started with sticky notes each of which contained a problem I identified from my research.
We then started trying to sort the stickies into groups. I initially found it difficult to stop thinking in terms of the categories I had already been noticing during earlier analyses of the data. This is almost certainly why it’s useful to have other people to do this task with! Mo jumped right in and started moving things around. Once we had figured out any groups at all, things started falling into place and becoming easier to sort. She ended up labeling most of the groups, which probably makes sense given that this was my first time doing this task. We were not discussing our choices at this point, which I suspect is an important part of this task. Just do the sorting, and figure out what it means later!
Next, PrioritizationAfter we’d created our groups, making sure that no group was obviously absurdly larger than the others, our next goal was to prioritize those groups by severity and number of people affected.
During the prioritization, Mo and I were doing a lot of talking (which you can see in the log file I linked on the pagure issue ). She first described our task, and then made a simple box chart into which to put the group names, with one axis being severity and the other being affected numbers of people.
We then discussed our feeling on how severe each group was, and how many people were affected. It was not necessarily obvious in the box chart, but there was some gradation within each category (we have ‘low’ and ‘high’ severity, and ‘many’ and ‘few’ people). Some things that were high severity were less high than others, for example.
At the end of this task, we determined that Budget Stuff and Local Resource Finding and Scalability were our priority for this release. We also decided that the next release should include Localization and User Onboarding, plus whatever came up between now and then.
Deep Dive/BrainstormingOn Wednesday, we took a close look at our two high priority groups for this release. The end goal here was to figure out what was actually possible to do, what the goals for those were, how success would be measured, and the specific tasks I would need to do to address those goals.
We took two hours to do brainstorming in the IRC channel, and Mo thought to turn on the meetbot logging tool ( Summary is here , Chat log is here ) shortly after we had decided that the budget stuff had too many unknowns for us to be tackling in this release.
While budgeting will not be a priority during this release, we intend to keep it in mind during the design process to offer some basic support. For example, events created through Hubs should provide fields in events for budgetary data like allocation, actual costs, and investment returns.
Local ResourcesWe then looked at the other prioritized group for this release: Visibility, scalability, and findability of local resources. Or, as Mo put it, it’s currently difficult to find or know about many Fedora resources, including people and events. This really seems to be the core of what hubs is about.
Getting our minds around this was a _huge_ task, and needed a lot of breaking down into smaller pieces. Happily, that group had existing sticky notes referring to the problems that I’d found in my research.
So, we started going through those notes, one by one.
Note 1:“There are a lot of different places that have information about Fedora-related events. This can make it difficult to know if you can’t find any nearby because they don’t exist, or because you haven’t looked in the right place. This makes it difficult to prioritize event attendance. There are also many different places to find non-Fedora-related but relevant events, which makes it difficult to prioritize Fedora sponsorship.”
We discussed the need for making the system attractive, useful, and inviting so that people actually use it. Otherwise, it’d end up being yet another place data is scattered to.
We considered the idea of pulling in Fedora events from other places, to make it more canonical in the short term. Unfortunately, most of the event information is in blog posts and mailing lists and wiki pages. None of these are especially easy to scrape those events from. Given that hubs will integrate blog posts and mailing lists into its notifications, it is theoretically possible that we’d be able to scrape event information from those, and then suggest adding them to the Fedora event calendar. However, as this is not an easy task, we are not focusing on it right now.
Mo suggested that our goal for the local resources topic as a whole should be:
if someone is looking for fedora-related stuff local to them, they will log into hubs, do a search or browse, and find the info they are looking for in regional hubs
And that a measurement of success in this goal would be that regional hubs would provide a canonical list of local resources ― people and events.
This suggests the need for a filterable, sortable master list of all regional hubs, members, and events.
Task: This means I need to make mockups of and tickets for the interfaces for the lists for hubs, members, and events.
The rest of the brainstorming session resulted in a clearer understanding of the interfaces for the members and events lists.
Note 2:"It would be useful for us to tie Hubs into social media so that people can access the types of social media that is popular in their countries if they want to do so (not everyone uses IRC natively). Eg Twitter, facebook, telegram, Eventbrite, instagram"
We discussed the use of the feed widget to support this. We already plan to have it support blog posts and mailing lists, as stated earlier, and this would be a perfect place to include social media posts.
My task for this note is to compile a list of regions and their social media preferences. I will need to connect with my interviewees (and perhaps others?) to confirm my existing information on this topic and check if I’ve missed anything. After that point, I plan to create tickets for the integration of both reading from and posting to those social media outlets.
Note 3:"Many ambassadors are local resources for their local Fedora community. It may be useful to make as many as possible of those resources easily available without having to go through an overworked ambassador."
We discussed the various ways in which the ambassadors that I spoke to acted as resources for their communities. We came up with a lot of ideas on how to handle the various types of resources that were relevant, as per the following:
A FAQ per each regional hub, where local ambassadors can list the questions and answers they get asked repeatedly and point to those to potentially