• Proposal 1: Joe
    • Tension: The unilateral decisions made early in combining onboarding squads have been making it difficult to pay contributors The way the stream had consolidated power took away autonomy of the squads and has delayed payments. This delay of payments had been blamed on the FDD system not working where the real problem lies in the way the squad was formed. (As evidenced by the system working in multiple other squads)
    • Proposal: Agree to an official hand off date when the DAO ops proposal is approved on snapshot by the stewards. Afterwards, the payment models and which squads exist are to be decided by the DAOops. Before, they will maintain consistency with the FDD processes. Let this serve as an example of legitimacy in how spin-outs and transfers of squads occur.
      • No squads, initiatives, roles, or streams will be forcibly combined by any individual or governing body without mutual consent of the governance of the streams involved they are currently in OR the express consent of stewards via snapshot vote
        • The stream they are in being defined by the workstream providing the budget
        • (KW proposal) - In the event a disagreement cannot be resolved within the workstream, the topic can be brought to the DAOops can review and offer opinion, finally stewards will ultimately decide when a budget request is made by either party - OK for Joe
      • DAOops (or any workstream) does not hold the right to determine the scope of any other workstream
        • DAO Ops does hold the right to create systems to inform the stewards and other contributors about the decisions a stream makes
      • Agree to an official handoff of DAOops payment administration on the day following a successful setup of the DAOops multisig for the creation of a DAOops workstream
        • Until then, any payments administered by FDD will use the FDD model for determining dRewards. After, they can use whatever model the DAOops stream wishes.
        • https://docs.google.com/spreadsheets/d/1-AYF28k2tyv0-eDhfqcLdqymCRcp6CdTsDgkflsAqMU/edit?usp=sharing
    • Clarifying Questions
      • Proposed handoff date: not set. (tuesday following snapshot vote)
      • Kyle: no need to have a vote, or the workstream formally approved per past decision - ok for joe
      • Annika: coordination structure? educating instead of mandating
      • Clarification from Joe: whatever stream's budget is being used should be managing how work is funded because they are the accountable party
      • Kyle: does point#2 extend bi-laterally, as in no workstream should determine the scope of any other workstream? Joe: yes
      • Kris: do you agree that as soon as the multisig is set up, FDD will send the funds? - Joe: yes, FDD will send the full amount on the day the multisig is ready (not waiting for tally)
      • Kyle: is point#1 basically a rework of point#2? For example, if onboarding is happening in multiple places, the onboarding efforst can't be combined without steward snapshot vote? - Joe: squad 1,2,3 were led by different ppl, squad 1 leader wanted to combine all 3 squads, but not all squad leads agreed, then squad 1 lead started making decisions that affected all 3 squads anyways. Where the budget is coming from is the one that should have the oversight of how the funds should be spent.
        • kyle: so we're adding consent here, but does it need a stewards vote if there isn't consent among squad leads? - Joe: yes
    • Reactions
      • Kyle: supportive of #2 (no 1 WS can control another WS what to do). Payments we got to a good spot in that FDD will send funds once multisig is created. I'm nervous abt the push for more steward votes here, usually that's a blocker/slows us down. Biggest contention is with the idea that any internal lack of consent should be elevated to stewards. 1st bullet point is confusing, would rather rework it
        • Joe: can we move to table this?
      • Sean: agree with Kyle. #2 and #3 seem fine, #1 is not workable as written
      • Kevin: #1 and #2 are already the current state of affairs. I support point #3, choosing hand off date for Ops funds
      • Annika: #2 and #3 are fine, there is some superfluity but sometimes good to have those things clearly stated anyhow. amendment: if no consent among squad leads, elevate to DAO ops 1st before elevating to stewards
      • Cali/Huxwell: fully supportive of #1 and #2, generall the whole proposal
      • Kris: agree with a lot of what's been said. voicing that this is triggered by what has happened with onboarding squad. also, all of the details of handover of funds was agreed upon a couple weeks ago in a gov proposal. point #2 - everyone agrees no WS has that power. would be good to write out budget projections so we don't spend a long time bakc & forthing on it
    • Amend & Clarify:
      • Joe: agree with what Kevin pointed out abt state of affairs. I wrote out my amendments in the text. No squad or stream will be forcibly combined without mutual consent of the streams. Point #2 no change. Point #3 change: funds sent in full on the day DAO Ops multisig is set up
    • Objections
      • Kyle objecting to give more time for ratifications
      • Consent to table it til next week
       
      Proposal 2 - Loie
    • Tension: Onboarding has been a constant issue - we're putting way more effort into it than value getting out. There's no ship for people to get onboard, and everyone would benefit if we paused & took some time to build that ship.
    • Proposal: Pause general Onboarding for 6 weeks, move to a cohort model
      • Stop the official review process for new applicants (Loie will continue to peruse incoming applications to make sure we don't miss any A players or perfect job candidates)
      • Stop the biweekly onboarding calls (keep the time slot, it will be used as a checkin call for the current cohort, everyone who has been onboarded before today)
      • Change the response email after applying to be "thank you for applying, please stay tuned as we prepare for the next cohort" instead of "you've been accepted, please come to biweekly onboarding call"
      • Stop 1-1 onboarding calls. (Except for folks who have been hired on to a very specific role)
      • Resume onboarding calls for new applicants 2nd week of January. Those onboardees enter a cohort of folks who are allied on their journey of joining GitcoinDAO.
      • Context: several Biweekly Onboarding calls have had 1-3 onboardees and 5 or more Gitcoiners (a ratio we can't afford when time is precious). We have lost several contributors who were "onboarded" bc there wasn't anything waiting for them on the other side of onboarding. Applicant reviews are not meaningfully filtering people out.
    • Clarifying Questions
      • Annika: how many do we have atm? loie: it's fluctuated
      • Scott: does it make sense to start the cohorting? loie: take a break from onboarding for like 3 weeks, even cohorting
      • Kris: do we announce people they are in the cohort, what do we with the calls? loie: yes, trish can make edits to mails, let people know that they are part of the cohort
      • Kris: Does this mean we will stop reviewing, and or the budget, team, etc. be without work?
        • Loie: Yes - would halt that work. Most will be very relevant to do other tasks, (ie support the existing cohort be effective)
      • Annika - are most of these people mostly paid by the DAO
        • Loie: Mostly DAO funded
      • Joe - Are we saying to stop the 1:1 calls for general DAO onboarding in the future (even once we bring it back?)
        • Loie: That is not mandated by this proposal
    • Reactions
      • Huxwell - This proposal might create cohesion with new cohort. Unsure if this will solve the onboarding experience. How might we capture the lurkers so they can create value? How might we convert the lurkers to actives
      • Kris - Support the proposal to enable focusing on other processes and strengthen the experience going forward. With the discord setup on roles. How do we enable people who are onboarded in other places, and have them fill out the correct roles to ensure Discord is not creating debt
      • Annika - Generally agree with support and this action. Concerned 6 weeks is the right amount of time. How do we ensure this is ready when the amount of time is up.
      • Sean - Generally supportive (cohorts is a better experience).
      • Joe - Less issues from his observation. Supportive of the sentiment. We have not done a design phase on the existing process. 6 weeks feels like a long time.
      • Kevin - Supportive of experimentation, and 6 weeks may be a long time, but the holidays and GR12 will eat this time up fast.
      • Kyle - Supportive (similar to Kevin's thoughts)
    • Amendment notes:
      • Loie: Prepping for 6 weeks from now being ready to onboard cohorts: a lot of the ppl ops efforts will be solidified (role documentation/work contracts, peer review process, hiring process, conflict res process).
      • Won't be reinventing the wheel when re-starting onboarding in 6 weeks. ie. plan to review the work Joe/FDD started and plan to leverage that.
    • Objections
      • No objections
    • Proposal passed
  • Proposal 1: Joe
    • Tension: The unilateral decisions made early in combining onboarding squads have been making it difficult to pay contributors The way the stream had consolidated power took away autonomy of the squads and has delayed payments. This delay of payments had been blamed on the FDD system not working where the real problem lies in the way the squad was formed. (As evidenced by the system working in multiple other squads)
    • Proposal: Agree to an official hand off date when the DAO ops proposal is approved on snapshot by the stewards. Afterwards, the payment models and which squads exist are to be decided by the DAOops. Before, they will maintain consistency with the FDD processes. Let this serve as an example of legitimacy in how spin-outs and transfers of squads occur.
      • No squads, initiatives, roles, or streams will be forcibly combined by any individual or governing body without mutual consent of the governance of the streams involved they are currently in OR the express consent of stewards via snapshot vote
        • The stream they are in being defined by the workstream providing the budget
        • (KW proposal) - In the event a disagreement cannot be resolved within the workstream, the topic can be brought to the DAOops can review and offer opinion, finally stewards will ultimately decide when a budget request is made by either party - OK for Joe
      • DAOops (or any workstream) does not hold the right to determine the scope of any other workstream
        • DAO Ops does hold the right to create systems to inform the stewards and other contributors about the decisions a stream makes
      • Agree to an official handoff of DAOops payment administration on the day following a successful setup of the DAOops multisig for the creation of a DAOops workstream
        • Until then, any payments administered by FDD will use the FDD model for determining dRewards. After, they can use whatever model the DAOops stream wishes.
        • https://docs.google.com/spreadsheets/d/1-AYF28k2tyv0-eDhfqcLdqymCRcp6CdTsDgkflsAqMU/edit?usp=sharing
    • Clarifying Questions
      • Proposed handoff date: not set. (tuesday following snapshot vote)
      • Kyle: no need to have a vote, or the workstream formally approved per past decision - ok for joe
      • Annika: coordination structure? educating instead of mandating
      • Clarification from Joe: whatever stream's budget is being used should be managing how work is funded because they are the accountable party
      • Kyle: does point#2 extend bi-laterally, as in no workstream should determine the scope of any other workstream? Joe: yes
      • Kris: do you agree that as soon as the multisig is set up, FDD will send the funds? - Joe: yes, FDD will send the full amount on the day the multisig is ready (not waiting for tally)
      • Kyle: is point#1 basically a rework of point#2? For example, if onboarding is happening in multiple places, the onboarding efforst can't be combined without steward snapshot vote? - Joe: squad 1,2,3 were led by different ppl, squad 1 leader wanted to combine all 3 squads, but not all squad leads agreed, then squad 1 lead started making decisions that affected all 3 squads anyways. Where the budget is coming from is the one that should have the oversight of how the funds should be spent.
        • kyle: so we're adding consent here, but does it need a stewards vote if there isn't consent among squad leads? - Joe: yes
    • Reactions
      • Kyle: supportive of #2 (no 1 WS can control another WS what to do). Payments we got to a good spot in that FDD will send funds once multisig is created. I'm nervous abt the push for more steward votes here, usually that's a blocker/slows us down. Biggest contention is with the idea that any internal lack of consent should be elevated to stewards. 1st bullet point is confusing, would rather rework it
        • Joe: can we move to table this?
      • Sean: agree with Kyle. #2 and #3 seem fine, #1 is not workable as written
      • Kevin: #1 and #2 are already the current state of affairs. I support point #3, choosing hand off date for Ops funds
      • Annika: #2 and #3 are fine, there is some superfluity but sometimes good to have those things clearly stated anyhow. amendment: if no consent among squad leads, elevate to DAO ops 1st before elevating to stewards
      • Cali/Huxwell: fully supportive of #1 and #2, generall the whole proposal
      • Kris: agree with a lot of what's been said. voicing that this is triggered by what has happened with onboarding squad. also, all of the details of handover of funds was agreed upon a couple weeks ago in a gov proposal. point #2 - everyone agrees no WS has that power. would be good to write out budget projections so we don't spend a long time bakc & forthing on it
    • Amend & Clarify:
      • Joe: agree with what Kevin pointed out abt state of affairs. I wrote out my amendments in the text. No squad or stream will be forcibly combined without mutual consent of the streams. Point #2 no change. Point #3 change: funds sent in full on the day DAO Ops multisig is set up
    • Objections
      • Kyle objecting to give more time for ratifications
      • Consent to table it til next week
       
      Proposal 2 - Loie
    • Tension: Onboarding has been a constant issue - we're putting way more effort into it than value getting out. There's no ship for people to get onboard, and everyone would benefit if we paused & took some time to build that ship.
    • Proposal: Pause general Onboarding for 6 weeks, move to a cohort model
      • Stop the official review process for new applicants (Loie will continue to peruse incoming applications to make sure we don't miss any A players or perfect job candidates)
      • Stop the biweekly onboarding calls (keep the time slot, it will be used as a checkin call for the current cohort, everyone who has been onboarded before today)
      • Change the response email after applying to be "thank you for applying, please stay tuned as we prepare for the next cohort" instead of "you've been accepted, please come to biweekly onboarding call"
      • Stop 1-1 onboarding calls. (Except for folks who have been hired on to a very specific role)
      • Resume onboarding calls for new applicants 2nd week of January. Those onboardees enter a cohort of folks who are allied on their journey of joining GitcoinDAO.
      • Context: several Biweekly Onboarding calls have had 1-3 onboardees and 5 or more Gitcoiners (a ratio we can't afford when time is precious). We have lost several contributors who were "onboarded" bc there wasn't anything waiting for them on the other side of onboarding. Applicant reviews are not meaningfully filtering people out.
    • Clarifying Questions
      • Annika: how many do we have atm? loie: it's fluctuated
      • Scott: does it make sense to start the cohorting? loie: take a break from onboarding for like 3 weeks, even cohorting
      • Kris: do we announce people they are in the cohort, what do we with the calls? loie: yes, trish can make edits to mails, let people know that they are part of the cohort
      • Kris: Does this mean we will stop reviewing, and or the budget, team, etc. be without work?
        • Loie: Yes - would halt that work. Most will be very relevant to do other tasks, (ie support the existing cohort be effective)
      • Annika - are most of these people mostly paid by the DAO
        • Loie: Mostly DAO funded
      • Joe - Are we saying to stop the 1:1 calls for general DAO onboarding in the future (even once we bring it back?)
        • Loie: That is not mandated by this proposal
    • Reactions
      • Huxwell - This proposal might create cohesion with new cohort. Unsure if this will solve the onboarding experience. How might we capture the lurkers so they can create value? How might we convert the lurkers to actives
      • Kris - Support the proposal to enable focusing on other processes and strengthen the experience going forward. With the discord setup on roles. How do we enable people who are onboarded in other places, and have them fill out the correct roles to ensure Discord is not creating debt
      • Annika - Generally agree with support and this action. Concerned 6 weeks is the right amount of time. How do we ensure this is ready when the amount of time is up.
      • Sean - Generally supportive (cohorts is a better experience).
      • Joe - Less issues from his observation. Supportive of the sentiment. We have not done a design phase on the existing process. 6 weeks feels like a long time.
      • Kevin - Supportive of experimentation, and 6 weeks may be a long time, but the holidays and GR12 will eat this time up fast.
      • Kyle - Supportive (similar to Kevin's thoughts)
    • Amendment notes:
      • Loie: Prepping for 6 weeks from now being ready to onboard cohorts: a lot of the ppl ops efforts will be solidified (role documentation/work contracts, peer review process, hiring process, conflict res process).
      • Won't be reinventing the wheel when re-starting onboarding in 6 weeks. ie. plan to review the work Joe/FDD started and plan to leverage that.
    • Objections
      • No objections
    • Proposal passed