resources/meetings/2020/

resources/meetings/2020/2020-05-29-meeting

Meeting — May 29, 2020

  • Attendees from last week: msiep, smichel, alignwaivers, salt, wolftune, loveliesbleeding, lishavita, adroit

  • Attendees (current): msiep, smichel, alignwaivers, salt, wolftune, adroit

Metrics

Discourse (over past week):

  • Signups: 1 -> 0

  • New Topics: 3 -> 3

  • Posts: 26 -> 22

  • DAU/MAU: 35% -> 37%

Snowdrift patrons: 120

Reminders on best-practice meeting habits

  • Review previous meeting notes especially when absent!

  • “NEXT STEPS” should be clear and actionable for assignee (who should double-check this for themselves)

  • Use chat in etherpad (and add your name)

Discussion mechanisms

  • open discussion

  • call for a round (“pass the mic” style, facilitator makes sure no one is skipped)

  • hand symbols

    • “o/” or “/” means that you have something to say and want to be put in the queue

    • “c/” or “?” means that you have a clarifying question and want to jump to the top of the queue

    • “d” means thumbs up, encouragement, agreement, etc.

    • “>” as an indicator of understanding someone and the point can be concluded, please move on

Facilitation by topic

  • There is a leader for each topic (generally the person who raised the topic), and the facilitator will assist the topic leader in the discussion via the etherpad chat

Notetaking

  • “???” in notes means something missed, please help capturing what was said

  • aim for shorthand / summary / key points (not transcript)

Review previous meeting feedback

  • adroit: good meeting, good to be ending early, glad to see roadmap be clarified

  • msiep: good discussion, good to see progress on roadmap

  • smichel: thought the topic discussions expanded to fill the time a bit which was unnecessary. Feeling tension on next step for roadmap development

  • lisha: really appreciated being able to be here and listen

  • wolftune: felt like when I facilitating, not the same as being in person and getting feedback more directly: Should err on the side of getting more feedback

  • loveliesbleeding: like lisha, glad to listen in. new to snowdrift but nice to be here

  • salt: feeling a little tension with the topics facilitated by the lead on each (not everyone is experienced or comfortable facilitating)

Last meeting next-steps review

Applying for external grants

Roadmap planning wiki page

  • NEXT STEP (wolftune): add intro to planning page that explains how to use it and add “previous phases” page https://gitlab.com/snowdrift/wiki/-/issues/25

  • NEXT STEP (salt): decide civicrm goals in current phase,

Current Agenda

  • alignwaivers: to streamline, relevant parties could just ‘>>’ in chat if in agreeance

Topic leader: “did you get what you need?”

Anyone with next steps: “Are you ok with the tasks and the topic notes?”

  • NEXT STEP (alignwaivers and everyone): try in this meeting, and post

Mozilla Incubators app update and… Grants!!! (alignwaivers)

  • https://www.mozilla.org/en-US/moss/mission-partners/

  • tldr: grants given adhoc to related projects : develop relationship / get involved, show up to mozilla stuff (not necessary to read but at bottom of the page of https://www.mozilla.org/en-US/grants/)

  • " Each grant made needs a champion inside Mozilla, someone known to our community. How can you find a Mozillian to champion your project?"

  • NEXT STEP(alignwaivers): make a post on discourse

  • salt: Wanted to check in and discuss what MVP is

  • salt: “I think the MVP is that we have a pipeline to bring projects that aren’t us from registration to payout”

  • salt: seemed like the ideal for mozilla would want start to finish with a new project

  • alignwaivers: nonprofit already in spring (that is just getting mentorship)

  • wolftune: Agree that if not a big cost, this is worthwhile is going. I want to have the parts in place, rather than rushing this

  • wolftune: in salt’s language, the pipeline exists (doesn’t need to have things flowing throug it)

front-end dev – update process idea/feedback (smichel)

  • smichel: we need to get unblocked making progress on the site. I’d like feedback on this idea for a process.

  • smichel: The current site and code has two types of pages with different [sass] styles (skins), one old, one newer

  • smichel: I could set it up so it’s easy to add additional different skins.

  • smichel: Then, the process for updating a page would be: create a new skin that uses dropped-in prototype styles, recreate the updated page in the prototype, and then drop the updated page in, using the new skin.

  • smichel: It’s hard to update styles on the site, but not hard to create a new skin and then drop in new pages that use it.

  • mray: So then there’d be 3 different skins, one, using latest css?

  • smichel: yes

  • mray: I’m not okay with there being 2 skins, and 3 skins won’t make it better. Quick changes on the website is what we are after, not find a shortcut. In the past have been able to implement in old styles, but don’t have an iteration process

  • wolftune: wondering how much of this is a communication issue.

  • mray: I’m fine with things changing outside of the things that I’m doing, if there is a process. I don’t want styles to be mixed up

  • adroit: If we are only changing styles, we could quickly iterate on the live styles by copying the live html into the prototype, where iteration is possible

  • NEXT STEP (smichel): Write out this process as a proposal, get iko’s input

front-end: navbar idea/feedback (smichel)

  • smichel: I think I could refactor the styles so that the header and footer are not skin-dependent, so they will always be consistent (even if content is in different style)

  • wolftune: your goal is an incremental improvement to get to one skin?

  • smichel: Goal is to make site design look less broken as we work towards getting to one skin.

    • smichel (post meeting commentary): This would be a little more total work, but I think worth it for the immediate improvement.
  • mray: this would be ideal to get to one skin, hard to say if this is viable without knowing how much time you will spend on this

  • salt: seems like we are using this front end haskell thing with some questionable aspects, agree with mray to wonder how much time is worthwhile to spend on this. Besides that, the header/footer elements being independent seem like a good idea

  • smichel: the headers and footers are seperate, but they currently each depend on elements from their respective skins

  • wolftune: sounds like this is in the code, not so much a design issue, consult relevant people maybe

  • NEXT STEP (smichel): Investigate further, ping chreekat about implementation

  • NEXT STEP (smichel): Write this out in detail (esp. pros and cons), get iko’s input

Shorten 48 hour late agenda window? (smichel)

  • smichel: I’ve put stuff up there that it seems reasonable to read before hand (within the 48 hr window)

  • smichel: doesn’t seem to be an appreciable difference between early and late agenda items

  • salt: I think 6 hrs is reasonable

  • wolftune: I think 12 hours make sense. 24 hrs makes the most sense. There’s a relevant tension of prompting people to know when things have been added — eg, post in matrix if you add an early item

  • adroit: I was originally thinking 24 hrs, but don’t think the day matters as much, the period of time

  • wolftune: I think smaller window in conjunction with matrix reference

  • alignwaivers: 24 hrs seems good, and necessity to say on matrix only if the lead

  • NEXT STEPS (alignwaivers): update the etherpad to reflect smichels proposal, consolidate two sections

Globalsign cert renewal or OSUOSL by August (wolftune)

  • wolftune: We had a goal to be transitioned to OSUOSL by the time the cert expires

  • salt: the cert only mostly matters for external facing stuff, and chreekat has transitioned a good portion of things already, so this might be trivial. Don’t see a reasonable reason to spend more time on this

  • NEXT STEP (wolftune): contact OSUOSL, (contact lance) say we have a deadline

  • salt: while we are on this topic, discourse, wiki, and blog are the ones that are required

carry-over topic: Civi in roadmap

  • NEXT STEP (salt): decide civicrm goals in current phase,

  • NEXT STEP (smichel): bug salt to do this next week because it is time sensitive


meeting evaluation / feedback / suggestions / appreciations round

  • smichel: could’ve pushed my topics faster, were mainly for a subset of participants, but this worked

  • adroit: I’m happy with everything

  • wolftune: felt okay about it overall, balance of facilitating and participating seemed okay. Would be glad for feedback, and encourage everone to give each other feedback

  • msiep: meeting was fine

  • alignwaivers: good meeting, glad with the >>

  • salt: good meeting

  • mray: nice meeting, appreciate organization