2018-05-01-Meeting

[matikin9]

Who's here?

• Nina
• Josh
• Tamura
• Alli
• Joshua
• Jim

What did we do?

Continue discussing a project framework. Tamura brought OpenAustin's Civic Tech Canvas as an example of what we should require new projects to fill out. We then reviewed the notes from last week to further flesh out ideas and bring up additional questions that need to be answered.

• Civic Tech Canvas
  • Gamify the tracking of the Civic Tech Canvas components? At least create a database and interface for projects to track their progress.
  • Create a sample project idea that uses the canvas as an example.
  • Create Github repo as template for projects to fork. Have it include the Canvas?
• Alli - for HFLA Team:
  • What does success look like? For Hack for LA? Conduct periodic surveys? Build self-monitoring into project workflow? Build community? Empower attendees? Create products?
  • Create Slackbot surveys?
  • How do we measure retention?
  • How do we keep people who are on a failing project and redirect them to a different project?
  • Group identity - focus on skills, identify people as shared resources? UX, developer, designer, data, etc. in order to redistribute talent.
  • How do we measure our impact?
• What are examples of alternative project types and what do their successful workflows look like?
• Potential alternative to a project group having its repo under the HFLA org is having HFLA as an Owner on the project group's Org.
• Project Requirements & Resources discussion:
  • A project is eligible for being listed in the newsletter after 4 weeks' worth of activity AND reaching Design/Prototype Stage.

Project Phases (6/29/18 Revision)

Discovery Phase

• The group will come up with a working name so that their research, work, and materials are documented and do not get lost if the group falls apart.
• The group will take notes each week to track their progress.
  • Create a separate Issue in the Github repo for each week's notes.
  • Who was there? Include group members' names plus Github handles if they have them.
  • What was done? What was discussed, researched, or decided on in this week's meeting.
  • What needs to be done? The group should end the night with next steps. This can be as general as "next week we discuss XXXXX" or as specific as assigning tasks to individual members to complete for the next meeting.
• All work created should be logged in the repo.
• The initial idea for what this will look like in practice is:
  • The group decides on a working name based on the project idea or general topic they're interested in.
  • The group approaches a Hack Night Lead to create a Github repository within the Hack For LA org.
  • Each week, the group creates an issue in the repo for their meeting notes.
  • Notes should contain names of participants, at least one sentence summarizing what happened this week, and at least one sentence summarizing the group's next step.
• A group in this phase is a Working Group until it generates one or more project ideas that it is ready to pursue. At that point the group becomes a Project Group.
• Once a group becomes a Project Group, it progresses from the Pitch Idea Phase to the Research Phase.

Research Phase

• The goal of a group in the Research Phase is to go through at least two rounds of filling out the Civic Tech Canvas in order to progressively define AND refine the project goals and strategy. Sections include:
  • Problem Statement
  • Users & Those Impacted
  • Features & Benefits
  • Key Activities
  • Partners
  • Project/Goals
  • Key Resources
• Consider what a successful project looks like for each team member. Make sure everyone is in agreement on the mission, vision, and strategy so that the team is in sync, working towards a unified goal.
  • What are existing solutions that have tried to tackle this problem? Have they been successful or not, and why? Look at work done by non-profits in this space, dig deep into government websites, look at projects from other Code for America brigades or projects created through fellowship programs.
• Talk to potential Subject Matter Experts. Invite them to Hack Night.
• Don't be afraid to meet with potential users and partners in person.

Design & Prototype Phase

• Design and build a prototype.
• Do it as quickly and as cheaply as possible using tools and frameworks that are free, and easiest to use for the group. Examples:
  • Photoshop
  • Sketch
  • Marvel
  • Invision
  • HTML/CSS, Bootstrap
  • Jekyll
  • Pen + paper
• Prioritize features for the MVP. The features should be implementable within 2-3 months.
  • Techniques include drawing a Value-Effort Matrix to identify features that are high value + low effort.
• This should be quick - 2 week deadline.

Pre-MVP Phase

• Publish something that will eventually turn into your MVP.
• Strict 2 week deadline for this phase.
• It will be ugly.
• This phase may already be satisfied if the prototype was done with code.

Minimum Viable Product (MVP) Phase

• Iterate on what was created in the Pre-MVP Phase.
• Develop the priority features to create a functional product.
• Set a hard deadline for the MVP - 2-3 months.
• Use free and open source tools/libraries as much as possible.
• Conduct the project management within the Github repo so that it's centralized with the rest of the project documentation.
• Once the MVP is complete, present it at Hack Night.
• Before progressing to the next phase, hold a retrospective session and reflect on whether the Project section of the Canvas was satisfied.

Testing Phase

• Continually test functionality, test with users and solicit feedback, and improve the solution.
• Focus harder on communication + outreach:
  • Identify and reach out to potential partnership organizations (non-profits/government).
  • Build up social media presence. Develop and follow a marketing/PR plan.
  • Focus on community outreach to the users of the solution. Survey and test with these users.
  • Identify and attend appropriate networking and community events.
  • Represent the project and give presentations about the project.
• A project that has reached this phase is eligible to present at Hack for LA Demo Nights.
• Consider what a successful end state looks like for this project, and what are the requirements to reach that point.
• ITERATE by continuously cycling through the phases, Testing -> Design + Prototype -> MVP, until the end state is reached.

Adoption

• Adoption is one possible end state for a project.
• Adoption the project is adopted by a partnership organization. Relationships built up through the course of the project's development.

What do we want to do?

Most of these are carried over from last week. Additionally contains questions to answer.

• [ ] [Jim] - Look up issue templates.
• [ ] [Nina] - Bring materials to make a UI Library out of felt. Start with Bootstrap UI components.
• [ ] Define what the project path to Adoption/Graduation looks like, also what alternative "end states" look like for various projects.
• [ ] Define what various project paths look like. Examples: data science/visualization projects, marketing campaigns, etc.
• [x] Define categories for the phase a project is in, which will be useful for the project being listed on the website.
• [ ] Define when a project qualifies for resources, like being posted on the website, being listed in the newsletter, or when HFLA pays for a domain/hosting/marketing/etc.?
• [ ] Design a way for project groups to submit their progress on the Canvas. Maybe start with Issue Template, and progress to an interactive webpage with data store.
• [ ] Create guide on how project groups will handle new team members, no matter what their background - on-boarding to get them up to speed, contributor workflow so they can jump in and help with the project
• [ ] Define responsibilities, like providing monthly newsletter updates for needs & status, representing their project and HFLA at events, adherence to Code of Conduct and Inclusion guidelines, and creating written material like blog posts.
• [ ] Define responsibilities of Project lead(s).
• [ ] Define potential sub-teams a project may want to create, such as Front End Dev, Back End Dev, UX/Design, Marketing, etc.
• [ ] Identify speaking opportunities, such as Big Data Day LA, SCaLE, CfA virtual seminars, etc. Encourage members to present at these opportunities, especially if they're interested in public speaking as part of their professional development.
• [ ] Create case studies as examples for how the canvas should be filled out.
• [ ] Define techniques/resources for project groups:
  • Project Management - Agile sprints, Kanban boards
  • Process - http://playbook.cio.gov
  • Product Management and Design - user personas, user stories, user surveys, prioritizing features
  • Icons - Font Awesome, The Noun Project
  • Hosting - Github Pages, Netlify
  • Fonts - Google Fonts
• [ ] Create workshops for hack nights on techniques or technologies, like how to design a prototype, how to use a Value-Effort Matrix, how to create user surveys, how to design user personas, how to use Github, how to use APIs, etc.

[matikin9]

I really like this idea of visual SKILL TREES for projects to interact with. It would give us a quick visual indicator of a group's progress.

https://www.google.com/search?biw=1920&bih=949&tbm=isch&sa=1&ei=MmnqWquNCsSSjwPz65_gAw&q=skill+tree&oq=skill+tree&gs_l=psy-ab.3..0i67k1j0l4j0i67k1j0l4.4347.4347.0.4522.1.1.0.0.0.0.82.82.1.1.0....0...1c.1.64.psy-ab..0.1.81....0.rRx52RuhLlY

[matikin9]

Check out this list of resources I compiled based on a current discussion in the CFA Slack about this exact thing: hackforla/governance#3 - Resources on Project Frameworks.

[matikin9]

Next meetings to discuss the framework:

• Friday 5/4 at Cognoscenti Cafe in the DTLA Fashion District with possibly Tamura & Josh.
• Monday 5/7 at the Westside Hack Night with Wes & Kegan.

[matikin9]

Visual diagram for easier understanding of the flow (as a finite state machine!). Circles are the states, or the Phase a project is in. Lines are the conditions or actions that define the next (or same) state.

There are some minor changes in this diagram from the notes listed above, with the main idea being that the Pre-MVP and MVP phases are only relevant for the first iteration that leads to the product launch. The Pre-MVP phase as defined isn't applicable to subsequent iterations. The Develop phase would be functionally the same as the MVP phase, except what's being developed is an additional set of features rather than the minimum viable product. I'm open to ways we can simplify this flow.

[tamurafatherree]

Sub-teams: add Documentation ("codestodian") and Data