Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ushahidi : Working openly and encouraging contribution from international development workers, activists and volunteers #32

Open
27 tasks done
Erioldoesdesign opened this issue Sep 7, 2018 · 13 comments

Comments

@Erioldoesdesign
Copy link

Erioldoesdesign commented Sep 7, 2018

Project Leads: @Erioldoesdesign

Mentors:
Eriol: @triaslucia @denefi

Welcome to OL6, Cohort A! This issue will be used to track your project and progress during the program. Please use this checklist over the next few weeks as you start Open Leadership Training 🎉.


Before Week 1 (Sept 11): Your first mentorship call

  • Complete the OLF self-assessment (online, printable). If you're a group, each teammate should complete this assessment individually. This is here to help you set your own personal goals during the program. No need to share your results, but be ready to share your thoughts with your mentor.
  • Make sure you know when and how you'll be meeting with your mentor.

Before Week 2 (Sept 18): First Cohort Call (Open by Design)

Before Week 3 (Sept 25): Mentorship call

  • Look up two other projects and comment on their issues with feedback on their vision statement.
  • Complete your Open Canvas (instructions, canvas). Comment on this issue with a link to your canvas.
  • Start your Roadmap. Comment on this issue with your draft Roadmap.

Before Week 4 (Oct 3): Cohort Call (Build for Understanding)

  • Look up two other projects and comment on their issues with feedback on their open canvas.
  • Pick an open license for the work you're doing during the program.
  • Use your canvas to start writing a README, or landing page, for your project. Link to your README in a comment on this issue.

Before Week 5 (Oct 10): Mentorship Meeting

  • Review goals & progress, bring in a topic expert if needed.

Before Week 6 (Oct 17 ): Cohort Call (Participation & Inclusion, Feedback Workshop)

Before the call

  • Bring an item you would like feedback on (README, landing page, session description, hacktoberfest issue)

Assignments (all optional)

  • Incorporate feedback from the workshop
  • Personas & pathways assignment
  • Think through community interactions
  • Facilitating at MozFest? Look at the ‘Running Awesome Events’ module

Before Week 7 (Oct 24): Mentorship Meeting

  • Review goals & progress, bring in a topic expert if needed.

Before Week 8 (Oct 31): Cohort Call (Build for Participation & Inclusion)

  • Follow up with participants from MozFest / Hacktoberfest with the next steps you planned during the call
  • Complete the midterm survey (due Oct 31)

Before Week 9 (Nov 7 ): Mentorship Meeting

  • Review goals & progress, bring in a topic expert if needed.

Before Week 10 (Nov 14 ): Cohort Call (Empower for Participation & Inclusion)

  • (optional) Implement ideas from the ‘see bias and block it’ breakout
  • (optional) Vision stand brainstorm prep -- if you’re not sure where to start for your 2min vision stand / demo for our final demo call, use this worksheet to brainstorm

Before Week 11 (Nov 21): Mentorship Meeting

  • Review goals & progress, bring in a topic expert if needed.

Before Week 12 (Nov 28): Cohort Call (Build for Understanding - Demo prep)

  • Before the call (optional)
    If you’re not sure where to start with your 2min presentation, you can use this worksheet to brainstorm.

Assignment (optional)

  • Incorporate feedback into your 2min vision

Before Week 13 (Dec 5): Mentorship Meeting

  • Review goals & progress,

This is your final scheduled call with your mentor! Be prepared to celebrate all you've accomplished and debrief your time together. We'll also be sending out a final anonymous survey for any additional feedback.

Before Week 14 (Dec 28): Cohort Call (Final Demos - Celebration!)

On the demo call, each project will have a chance to share:

  • an introduction to your project,
  • and update on the progress you've made, and
  • how others can help you and your project

This issue is here to help you keep track of work during the first month of the program. Please refer to the OL6 Syllabus for more detailed weekly notes and assignments past week 4.

@andyl
Copy link

andyl commented Sep 9, 2018

I'm work on communication tools for first responders - interested in offline / low bandwidth / intermittent connections & look forward to hearning more about your project.

@justinscherer
Copy link

Hey @Erioldoesdesign We decided to keep the two Ushahidi issues separate. I created mine over at #109 Feel free to remove Bonface and I from this one.

@Erioldoesdesign Erioldoesdesign changed the title Ushahidi Ushahidi : Working more openly with our current and future users and helping them contribute Sep 18, 2018
@Erioldoesdesign
Copy link
Author

Erioldoesdesign commented Sep 19, 2018

Vision or Mission Statement - Final


I’m working with Community development workers, international development workers, activists and volunteers to first, understand what the barriers* to contribution are and test/build a method/framework so that Community development workers, international development workers, activists and volunteers can be an integral part of the contribution process and can see clearly how their experiences and input affects the tools that will help them with their causes.


*Perceived barriers to contribution:
Int devs, community dev workers, activists and volunteers (hereby referred to as contributors) don’t always want to learn how to code to contribute
Usertesting and interviews may make the contributors feel more like the ‘subjects of inquiry’ and less like a ‘contributor’.
Contributors knowledge and expertise may be wrapped up in wider narratives/problems to do with the community/international development space. Isolating a particular GitHub issue that they can understand and contribute insight to is a challenge.
Tech as a tool and a concept doesn’t appeal to contributors as it doesn’t typically fit into an ‘evidence based’ industry like community development/international development. It’s above and beyond their roles to participate in tech.
Larger orgs may have dedicated tech support/role/volunteers whereas smaller orgs will not have this and may rely only on volunteers or not at all.

4 key areas: Time pressure, relevance to work, ease of adoption/contribution, Tech is scary

@Erioldoesdesign
Copy link
Author

Erioldoesdesign commented Sep 26, 2018

Link to my Moz recommended Open Canvas 1

screen shot 2018-12-05 at 11 43 42

Link to my Mentor recommended Open Canvas 2 TBC

@justinscherer
Copy link

Vision statement feedback:

understand what the barriers to contribution are and test/build a method/framework so that Community development workers, international development workers, activists and volunteers can be an integral part of the process and can see clearly how their experiences and input affects the tools that will help them do good with their causes.

Perhaps state explicitly what they are contributing to and to what end?

@triaslucia
Copy link

Vision or Mission Statement - WIP

I’m working with Community development workers, international development workers, activists and volunteers to first, understand what the barriers to contribution are and test/build a method/framework so that Community development workers, international development workers, activists and volunteers can be an integral part of the process and can see clearly how their experiences and input affects the tools that will help them do good with their causes.

You got all what you need in your vision...I think it just need some small text correction :)
For instance if you explain here you want to go User-based, that will help /support theidea of taking into account their experiences and it´ll frame the way you´ll do it.
Great job so far @Erioldoesdesign !!
👍

@abbycabs abbycabs added this to the Cohort C #mccohortface milestone Oct 5, 2018
@Erioldoesdesign Erioldoesdesign changed the title Ushahidi : Working more openly with our current and future users and helping them contribute Ushahidi : Working openly and encouraging contribution from international development workers, activists and volunteers Oct 9, 2018
@owenjoseph
Copy link

Hi @Erioldoesdesign. I’m very interested in following this issue, as both a non-techie myself and as a project leader who would like to encourage / enable more non-techie contributors.

FWIW in my experience with our project at Hack for L.A., the main obstacles I perceive are:

  • potential non-techie contributors assume they can’t add value,
  • design or content-focused contributors aren’t continuously involved in the process, and lose interest, and
  • we’re using GitHub, which, as a platform, is not inviting to non-techie types (I’ve got 5 years experience with JIRA as a Project Manager, and scaling the Git-mountain was still an undertaking for me)

I'm still new to GitHub, so I wonder if you or others reading have experience using it as a version control system for non-code assets.

Cheers!

@Erioldoesdesign
Copy link
Author

Erioldoesdesign commented Dec 5, 2018

Roadmap

Goal 1 - Engage with at least one group that has used Ushahidi platform before.

  • Send an initial engagement message to Bristol Women’s Voice (BWV) https://bristolstreetharassmentproject.ushahidi.io/

  • Ascertain whether BWV would want to be updated on the progress of these issues and the contributions made by them

  • Send a request to SWIDN (International development workers meet-up) to see if I can do a lunchtime session or an evening talk on OSS and the barriers to them.

  • Send a request to Bristol tech Volunteers to see if I can do a lunchtime session or an evening talk on OSS and the barriers to them.

  • Send a request to Bristol Tech 4 Good to see if I can do a lunchtime session or an evening talk on OSS and the barriers to them.

  • Reach out to one international group as a longer term project outreach. (Mapping Media Freedom)

Goal 2 - Via survey information collection, discussion, interviews or other research methods; discover/validate the barriers to contributing to OSS tech/code projects are.

  • Have a set of questioning for a 30 minute meeting ready for BWV meeting

  • Have a set of questioning for a 30 minute meeting ready for SWIDN meeting/workshop

  • Assess and turn research from Hacktoberfest and Mozfest into guidance on barriers

  • Sound/video record the meetings/workshops

  • Based off in-person learnings and desk research, review tools which could address the barriers to contribution.

  • Compile tools and assess gaps

Stretch goal!

  • Meeting with an international group Mapping Media Freedom

Goal 3 - Design a potential way for the int dev, activists and volunteers to contribute based off the information gathered in goals 1 & 2

  • Create a google form/type form of these issues and trial this method of responding/contributing to issues.

  • Investigate a way the above can be automated

  • Investigate other methods of contribution including but not limited to: Setting meetings with a developer & an international development worker (IDW), larger hack events that are IDW focussed and dev focused to get all people in the room. (Some progress)

  • Go through backlog of Ushahidi tickets and pick 5 that are relevant to BWV’s work plan around street harassment - Done

  • Go through backlog of Ushahidi tickets and pick 5 that are relevant to general international dev workers work.

Stretch goal!

  • Go through backlog of Ushahidi tickets and pick 5 that are relevant to Mapping Media Freedom’s goals

Goal 5 - Gain at least 5 contributions from my target groups or beyond.

  • Through the meetings and pilot test case with BWV’s gain 5 contributions to the platform through the method’s identified in early goals.

  • Publish findings in article and paper format.

Stretch goal!

  • Retain engagement from a target group. Investigate a weekly or monthly contribution ‘newsletter’ ‘email alert’ or regular events.

@Erioldoesdesign
Copy link
Author

Findings from Hacktoberfest:

  • Dev groups need 1-2 big issues to work on together that are broken down into clear tasks.
  • Less exp'd devs need smaller tickets to work on individually to feel sense of achievement.
  • For a stand alone event, 4 hours is not enough time to make much progress on an issue.
  • Context from the users (my target group) is useful but best summarised.
  • Facilitating a group session of a mix of developers/coders and the target group is beneficial to the process but difficult to organise.

Findings from Mozfest session:

  • Accessing educational institutions for a source of contributors requires moderation/engagement/curriculum by-in.
  • Again, user context is useful but complex. 'Needs translation/simplification'.

Findings from Google code-in:

  • TBC Google code-in still in progress

@Erioldoesdesign
Copy link
Author

Findings from meeting with Bristol Women's voice (BWV):

The issues picked for BWV are:

Obfuscation (formerly "Anonymization") v2 #3181
ushahidi/platform#3181

Notes: The admins find it useful to know precise location of a report/response in order to lobby local authorities/government for better provisions (more street lighting, remove bushes etc.) in high volume response/post areas or extreme instances. Allows them to take direct action.
There is no need to know a persons name but certain demo graphics are very useful for informing policy.
Admins across BWV all know the details given in a post and there are policies in place internally to safeguard that information. Within this org there is no need to have multiple levels of access to users data at the moment.

Semi-Anonymous Posting #1571
ushahidi/platform#1571

Notes: BWV currently ask demographic questions as part of their survey set up but indicate it would be useful to be able to collect this in a protected way. BWV never want a responder to become a 'user' e.g. sign up for an account on the deployment as the nature of the responses/posts are typically one off or even if there was multiple responses/posts by one person then they do not need to be connected yet.
Responders don't tend to check back after posting once or multiple times unless they experience another issue. Follow up is hard so a way of following up with a responder reliably and privately would be useful

Anonymization of Reporters Mobile #2685
ushahidi/platform#2685

Notes: Hesitation to automatically record responder mobile location. Responder may not be in the place that it happened and may be reporting it later at home or days/weeks after the incident. Responders should also be notified that their GPS could be used before it is used.

Allow changing map icons #1436
ushahidi/platform#1436

Notes: BWV say this could be useful for outside campaign uses but it's not essential. More useful would be colour coding (which exists but they struggled to discover)
They might be interested in icons that describe the type of offence (speech bubble as hate speech etc.)
They are most interested in this if it helps/encourages other responders understand and write their own responses.

Custom Icons #1941
ushahidi/platform#1941

Notes: See above re. changing icons.

BWV then talked about some innovations that would be useful without issues to prompt including:

  • A critical mass or 'hotspot' of responses/posts in either a configurable or non-configurable area that will send an email alert to the admin to investigate. Non config would be any geo area that receives over 10 posts. Configurable could be a combo of number of posts in geo area, type of post, timing of post etc. Semi connected to ML investigation: Display meta information about results from ML tools ushahidi/platform#1681

  • Ability to automatically redirect a responder to a webpage or document that will help them e.g. they send a report about hate speech -> get a message about a resource by BWV to recover from Hate Speech threats or where to go for legal advice. No current issue in Ushahidi repo.

  • Ability to have weekly email digests of new posts. Admin often forgets to check in on deployment so would like an email digest of new posts. Covered in a private issue within an Ushahidi account.

Glossary:

Platform = An instance of the Ushahidi data collection product is referred to as 'platform' or 'a deployment'

Report/Response/Post = A single instance of a person completing a response to a survey on a particular deployment.

Responder = A person responding to one of Bristol Women's Voice surveys on the Ushahidi platform about street harassment

Admin/s = The person/s that own the platform deployment of Bristol Women's Voice street harassment

@Erioldoesdesign
Copy link
Author

Who are my users? - Write Personas to validate

Non-techy personas

Persona 1 - (Individuals in) Charities/NGOs/Non-profit orgs - Fans & Skeptics - Need Most.
These are the people that work within small to medium Charities/NGOs/Non-profit orgs. They tend not to have a technical person/s in the org and don’t typically rely on tech to solve their problems. They could be national or international working or both. They are typically small staffed and overworked and low on resources/cash for tech.

Persona 2 - Individual international development workers/consultants. Fans - Need.
These people typically advise small, medium and large Charities/NGOs/Non-profit orgs and help build programs (for the charitable work) and proposals/grant writing that can include tech as part of the program. They are a swing factor for orgs that engage with them.

Persona 3 - Volunteers & Activists - Fans & Skeptics - Need most.
These are the people that drive small to large causes and initiative usually within their local/national areas. They are typically more focused on the cause and the people impacted than the ‘tech’ and how that can serve the cause. They are fans of ethical means in which to achieve ‘good’ for their cause but skeptical that tech can solve complex ‘human’ problems

Techy personas (support the effort)

Persona 4 - News, media and Journalists - Skeptics.
These are the people that hold our org reputation in their hands to some extent. They can also be part volunteer/activist persona too. They are hard to convince and we are both wary of them and them of us. There are dangers with working with these people due to the potential reputation risk.

Persona 5 - Technical people working in Charities/NGOs/Non-profit orgs - Fans - Need most.
These are the people that work in the orgs alongside the non-technical people. They don’t typically need help/convincing of the benefits of tech solutions to humanitarian problems but they tend to be a strained resource (if they exist) in these orgs. They could be a great source of insight and feedback on how to engage and work with the non-techy people in these orgs. There is also potential to have these people act as a gateway/buddy to contribution.

Persona 6 - Technical people not yet volunteering - Need.
These people are technical but they sit outside of both the humanitarian charity sector and the technical sector. They could be doing a technical job that is not in anyway related to humanitarian work. These are people that could support the technical people within humanitarian orgs to help the non-technical people contribute in ways in which they feel happy to. They may or may not have contributed to OS before.

Persona 7 - For profit businesses - Fans.
These are both the technical or non-technical people that sit in businesses and have some corporate responsibility. They could be allies and advocates and allow for the employees to ‘give back’ during charitable hours or facilitate and support events that engage with people in Charities/NGOs/Non-profit orgs.

@Erioldoesdesign
Copy link
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants