The following notes began mid-way through the Thursday morning panel with PMC members, regarding participation, future plans, and PMC strategy approaching the upcoming transition. I apologize that the introductory material is not here, but perhaps someone else has additional notes to add!
Q: There's a desire for more assistance, but is there a published backlog of areas in which to help?
YA: There is a backlog maintained on GitHub for issues. Also a "features" category on Forum to discuss new feature development & vote them up/down. "Behind the Repos" newsletter discussing needs, issues, and activities. Will be doing more outreach to increase visibility.
WB: The PMC (and future leaders) definitely need to hear feedback about peoples' and organizations' opinions about the future. Not just during this meeting, but continually. They want more participation & ideas, but it requires people stepping up.
SG: This event can be a space to make suggestions & explore the benefits and drawbacks of them. It's important to consider how your skills & resources can help this project. If people have been interested in areas like governance during this event, they may consider helping with groups working on those issues over the long term. Don't rule out potential contributions because you don't know the exact form. Take a risk.
Q: Has the overall product strategy been set or are people being asked to actively participate in its development?
RA: As ODK grows in usage, the product vision will mature, and the relationship between the two will grow more clear.
SG: What are the barriers that people are feeling blocking from participation?
YA: Reiterating the lack of clarity about needs.
COMMENT: Maybe if there is some sort of authoritative overview of what's going on, what are the needs, etc. Seems to be too much to follow. Forum sends out a summary but would like something more curated.
COMMENT: Reiterate the value in codifying & specifying mission & values. It's what unifies ODK1 & ODK2. It could help drive both of them forward & blend them, and help other orgs that want to contribute understand the goals.
COMMENT: Not a technical person, although others on their team are. Cultural blocks to contribution. Need for "marketing" or "business development" to help people understand what is needed to sustain the project. Why don't we contribute? We don't know if we should, or how.
COMMENT: Org is unsure if their would would be beneficial to others, and it's hard to know that without taking the time to understand. Hard to invest the time if it's not clear that their contributions would be valuable.
Q: Probably different ways to incentivize different categories of non-participants. What are those categories, and what would help?
YA: We don't want to prevent forks. If we can't reach consensus, or people need to innovate differently, it's an available option. But the project should understand why people are forking, and if there are ways to prevent it such as making ODK more flexible. For newsletter, there may be better people to write it than developers -- i.e., new ways for non-developers to participate. When they reached out to the existing community, it's been hard to get them to start contributing. But when they approach "outsiders" the response & contributions are very strong.
Q: What's the difference between pushing & pulling contributions from others? Some people may not be able to do the extra work to contribute back. Should the ODK team go seek out those changes, and then do the work to merge them?
WB: Not always clear where the changes are that people are making. We may be moving too fast and might need to slow down to make sure things don't fall apart.
SG: When people are time-constrained, the extra energy required to break free of the inertia can be too much. Can the process be made easier?
COMMENT: For a service provider or implementer, what's the best way to transmit end-user concerns & comments back into the project?
YA: We're still figuring out the right balance for the forum, but the areas like feature requests are a start. Scaling back the requirement to use GitHub. Just get it on the forum and it will be read & treated appropriately.
COMMENT: Even if you don't have time to solve a problem, at least describe your concerns and make them public. Getting them into a place like the forum will at least give it a chance at being addressed. If not, it may never happen.
SG: It's OK to say you don't have time, or alternatively, to offer time if you have it! Helps bridge communication gaps. Always err on the side of "too much" info.
COMMENT: A lot of the feature needs that their org needed had to be created through their own means. They feel that ODK 2 came too late, and they had to (pre)invent the wheel previously. Need a common way to talk about longer-term workflows, visualizations. A way to build features that will help each other.
Q: Are there any routine meetings for developers to communicate real-time about needs or offers?
YA: Nothing currently, has been under consideration and a priority. Challenging to think about a way for people to interact that balances time zones & other barriers. Also considering "office hours" for Q&A by developers. A challenge of life under UW has been an inability to respond to the need for large-scale collaboration that would help with the forks & feature drifting, upstream contributions, etc. The new structures will aim to do better at supporting those activities.
WB: ODK 2.0 is doing weekly telephone calls starting immediately. Waylon is coordinating.
YA: Collect has a new beta program.
SG: If someone wanted to start/launch a meeting around an interest area, how would they start doing that?
WB: Person with idea should head to the forum with a call for interested parties and to discuss logistics. Person leading the meeting should consider time zones/scheduling, have a clear topic & focus, limited agenda each time. Don't want the meeting to wander.
YA: If you want to do stuff, do stuff as much as you can in a community way. If you want a meeting, announce & coordinate on forum. PMC is happy to provide tools, assist with planning, etc. But first step is identifying a gap & making it clear what's desired.
COMMENT: Having a meeting-specific Slack/chat channel is helpful, so people can come in after the fact and visually catch up on the conversation.
SG: Rotating time zones can help when there are large geographic gaps so the "burden" is shared.