Team questions for Org sandbox

[sdimran]

Dependency

• [ ] Depends on if there are questions related to Org during the week for PM's to address or bring to Org meeting on Sunday

Overview

As a team, we need to make sure we are getting input from the Org when required and questions are not being missed otherwise they will become a bottleneck to the progress of the project and impact our release timelines. this issue will help track the questions for team to advise to PM's and Org

Action Items

• [ ] PM's to review questions in comments every week
• [ ] PM's to address questions and loop in Org as required either during the week or at the Sunday meeting by adding in the questions to the agenda for #101

Resources/Instructions

Resources

[Aveline-art]

1. Can you confirm that every HFLA project have their own unique emails with a @hackforla.org domain? If not, can the org arrange for it?
2. Can we get a short list of roles we would need to have listed for the qualifier's page role selector? So far, we have
   • backend dev
   • frontend dev
   • designer
   • pm (program, project, product)
   • researcher
   • data scientist
   • content writer
   • marketing
   • ops
3. What is the current single source of truth for project data? Meeting time data?
   • Also, can we take ownership of the part of the project data that we need? The reason for this is because in order for our product to be performant, we do need to cache the data. Since we are going this far, it would make sense for us to take ownership of it, at least on a temporary basis until it moves over to peopleDepot.
   • For reference, this is the projectData we want to take ownership of that will eventually move to peopleDepot:
     • name
     • description
     • program areas
     • logo (most likely link to permanent s3 asset storage)
     • technologies
     • roles
     • PMs, feel free to add more as required
     • Note: meeting times are not included, as we are quite happy with VRMS managing that data for the time being, and we have an optimal strategy for caching via their API
     • Do a pull from the website project, via just notification when new projects are updated.

[sdimran]

Question from Design: clarity for the requirements around availability selection. we currently have a calendar. can we change this to a different user experience based on some of the feedback from our usability testing. clarity around the reason we don't want to use "buckets"

Answers: @jenchuu

regarding why we cant use the time ranges : discussed with stakeholders that because of the international nature of our volunteers, time buckets wont work since we have to match time zones and some of them are in half hour differences. this will be a nightmare in terms of Parsing back to hackforLA meeting times.

regarding the current design of the availability selection calendar, we discussed that we were hoping to provide a better user experience as based on testing a few users were confused about the selections. it came down to the fact that this style of availability selection is not reinventing the wheel as it already exists in apps like when2meet and others. we can increase the understanding of the user through other means but at this point with the limited testing we've done its better to get to MVP and really see if its a larger problem. POST MVP we can again revisit the idea if it proves to be a pain point.

[Enzyme3]

This is a follow up to Ava's comment above Here's the tentative DB schema we have right now:

Please:

• ignore the tables with red x's: these are join tables
• review the opportunity table (red circle) and confirm that our team will be the source of truth for the data in that table. Are we missing something, is some of that data owned by other teams?
• review the tables with green circles and let us know where we should go to find that data. My understanding is that the data is to be owned and exposed by People Depot but it may not be ready for our timelines? Then who should we reach out to in the interim? Here's a link to their known schema
• review the recurring_event table with the orange circle. We have connected with the VRMS team who has provided us with the endpoint that contains the data. However, they don't have a list of roles that should attend a particular meeting. E.g. for a Tuesday meeting at 6PM, is it an all team meeting, is it a developers meeting, UI/UX meeting, etc.? This data is kind of contained in their description or title field, but its not super practical to parse that.
  • how should we proceed here?

[sdimran]

@ExperimentsInHonesty if you have some time this week, could you review the above questions from the dev team and advise. below are my comments @Enzyme3

opportunity : as civictechjobs we will be the source of truth for this information but like you have mentioned, VRMS team owns the meeting time data.

green circles: yes this data should be owned by the people depot team but their timelines are relatively unknown. in the interim one idea that was discussed was to use a process similar to the website teams of using github issues in a specific format to collect those fields of data and uploading them on the website at a predetermined cadenceexample of the website teams issue.

recurring_event: is it possible for the VRMS team to add a data field to indicate which role this meeting is for? aside from that thought we can confirm with bonnie if it is necessary to have the specific role the meeting is for included as a field in our data model for MVP1. A workaround could be to simply display all team meeting times in the search page results based on the availability selection and then list the individual role team meetings (dev, design, research) on the project card itself with a bolded border etc. Users would just filter based on their overall availability and then review the individual role team meeting timings after.

[Enzyme3]

green circles: yes this data should be owned by the people depot team but their timelines are relatively unknown. in the interim one idea that was discussed was to use a process similar to the website teams of using github issues in a specific format to collect those fields of data and uploading them on the website at a predetermined cadencehttps://github.com/hackforla/website/issues/2287.

If we have to we can use that model going forward, we'll still need a dump of the current data that the website team has (unless someone wants to go thru all the old issues and re-ingest it). Who can we reach out to to request that export? And ideally this would be a recurring export and NOT a one-time snapshot.

recurring_event: is it possible for the VRMS team to add a data field to indicate which role this meeting is for?

Haven't requested it yet, but it doesn't appear to be a trivial task for them. And yes, would be good to confirm if it's required

[Aveline-art]

Notes, post meeting May 29, 2022

• every project will have an @hackforla.org email; some projects will have multiple emails, but for the purposes of our project, there will only be one @hackforla.org email used for project to post roles
• this is the most up-to-date list of roles. that said, vrms might have some additional roles in their database
  • backend dev
  • frontend dev
  • designer
  • pm (program, project, product) Note: all these are pooled under pm, not separate roles
  • researcher
  • data scientist
  • content writer
  • marketing
  • ops
• the source of truth for project data is from the website project; we cannot take temporary ownership of the data due to capacity issues in the website project to change the way they are pulling in data
• for the technologies table, the data will come from the website project
• in addition to technologies, we also need fields for
  • languages, which are pulled from the github api
  • tools, which comes from the website project
• officially speaking, the difference between tools and technologies are that technologies are specific to developers (Django, React, Postgres, etc) and tools are everything else (zoom, Google Doc, Figma etc)

[hkimsummer]

@ExperimentsInHonesty

Findings from New Volunteer Survey

Please view the slide deck here.

Main Insights:

• Volunteers find it important to work for a good cause
• Volunteers are seeking career development opportunities
• Most volunteers find HfLA through LinkedIn or their existing network

Recommendations from the UXR Team:

• Position Civic Tech Jobs as a way to support a good cause while gaining new skills
• Provide more project details to increase engagement

Please let us know if you have any questions!

[Enzyme3]

Saving some links here

• https://github.com/hackforla/website/tree/gh-pages/_projects
• https://github.com/hackforla/website/tree/gh-pages/_data
• https://github.com/hackforla/website