#98 Diversity decision making process
Closed: complete 3 months ago by jflory7. Opened a year ago by amsharma.

I was trying to work on https://pagure.io/fedora-diversity/issue/89 since sometime now and I am facing difficulty in gathering feedback and making a final decision here. This makes me think that, if we create some decision making process for diversity team, it will help move things forward.

I purpose lazy approval for trivial issues and full consensus for major issues.

Lazy Approval - This means general consent is assumed unless valid objections are raised within a period of time i.e. 10 days along with minimum one positive vote (+1). Votes can be casted by any approved member of diversity team. The member who is purposing the change/issue will not be eligible for voting. This process is used for decisions with short-term consequences and which can be easily reversed. Any team member can ask for the deadline to be extended or the decision escalated to require full consensus.

Full Consensus - More significant decisions are made through a process of full consensus. In order to pass, these decisions need three positive votes (+3) and no negative votes (-1). The votes can be casted by any approved member of diversity team. A negative vote immediately halts the process and requires discussion. Therefore, in order to remain valid, negative votes must be supported with a specific concerns about the proposal, and suggestions for what could be changed in order to make the proposal acceptable.

@jonatoni @bee2502 @jflory7 .. please share your opinion. Thanks.


Metadata Update from @amsharma:
- Issue assigned to amsharma

a year ago

Metadata Update from @amsharma:
- Issue priority set to: needs review (was: awaiting triage)
- Issue tagged with: improvement, needs votes, new change, type - docs

a year ago

Metadata Update from @amsharma:
- Issue set to the milestone: Fedora 30 (to May 2019)

a year ago

I think we should have at least one +1 for the lazy approval, and a deadline of 10 days.

How many people in the total voting pool? I think we should have some requirement for Lazy and a higher bar for full.

@jonatoni What if we don't get that +1 within 10 days?

@bex by total voting pool, you mean who all are eligible to vote?
That is a good point, we need to define that too. Team admins or all members etc..
some requirement for lazy like the minimum vote ?

@jonatoni What if we don't get that +1 within 10 days?

IMHO, if we can't get even two +1s (it should be more than the person who proposed) in 10 days we have a much much larger problem.

@bex by total voting pool, you mean who all are eligible to vote?
That is a good point, we need to define that too. Team admins or all members etc..
some requirement for lazy like the minimum vote ?

This is critical otherwise things get stuck waiting on consensus when it actually already has them.

Considering the inputs from @bex and @jonatoni I have updated the process in comment#0. Please check.

I think this still needs a definition of "eligible members". Also 10 days is a LOOOONG time. Why do we think it takes so long for a ticket to get read? That seems like an indicator of a problem.

The full consensus has no time limit - how do you know you have no -1s if they can come forever?

I added my comment, just to clarify what we call approved D&I members - otherwise it looks great :)

Thanks @jonatoni suggestion accepted :).

I have added my suggestions in the doc to make the process more defined, but I like the overall outline :) nice work, @amsharma

Thanks @bee2502 :) . Suggestion accepted. Now this is only waiting on @bex , rest of team is fine with it. Thanks,

All comments are addressed and resolved.
Please have a look https://docs.google.com/document/d/1jT_a_nVgUnIwIIn9uWmw9P3iQ0hfiVtC7qoQ1FAO03c/edit?usp=sharing and I will raise a PR for the doc site for this content. Thanks.
@jflory7 @bee2502 @bex @jonatoni

All comments are addressed and resolved.
Please have a look https://docs.google.com/document/d/1jT_a_nVgUnIwIIn9uWmw9P3iQ0hfiVtC7qoQ1FAO03c/edit?usp=sharing and I will raise a PR for the doc site for this content. Thanks.
@jflory7 @bee2502 @bex @jonatoni

I have suggested some new edits to the language in the last section.

PR - https://pagure.io/fedora-diversity/pull-request/105
@jflory7 Please review and merge at your convince, Thanks.

I also suggest that to follow this practice that contributors opening the PR should not merge it but get it merged by other team member. Thanks.

Metadata Update from @jflory7:
- Issue set to the milestone: None (was: Fedora 30 (to May 2019))

a year ago

@jflory7 comments incorporated, please check and merge. Thanks.

Hi, this is late feedback but I missed this discussion after reviewing #105 and wanted to suggest the following changes to the lazy approval process:

  • General consent is assumed unless valid objections are raised within 7 calendar days
  • Remove requesting an extended deadline in favor of only requesting a switch to full consensus voting

Lazy approval consent should be assumed unless objections are raised (i.e. no votes are required). Additionally, the time period for voting should be fixed to seven calendar days. This is similar to the policy already used by the Mindshare Committee. However, I prefer fixed time periods because there is no ambiguity for how much time a decision needs. I prefer to be explicit to avoid confusion about how much time a decision deserves. Since lazy approval items are generally low-risk tasks, I do not see this as harmful.

Additionally, I prefer to have only one pathway for requesting more time on an issue. A D&I member should request escalation to full consensus instead of asking for an extended deadline since we do not document how long extensions last. I believe a -1 vote should act as a "stopper" even in a lazy approval decision until feedback is addressed. If a member thinks a decision needs more time for critical analysis, they should request the decision use the full consensus process.

@bex:
IMHO, if we can't get even two +1s (it should be more than the person who proposed) in 10 days we have a much much larger problem.

Hi Brian, could you please help me understand why the lazy approval process should have a voting requirement? I do not see other committees with this requirement. I think the purpose of lazy approval is to reduce barriers for low-risk decisions. It would be helpful to see a precedent for this in governance models used by other groups like the Council and Mindshare. I prefer to leave it open to only block on -1 votes as the Mindshare Committee does.

@bex:
Also 10 days is a LOOOONG time. Why do we think it takes so long for a ticket to get read? That seems like an indicator of a problem.

The current proposal suggests 14 days for full consensus unless the voting threshold is met. I think this is apt. This team is volunteer-led. Members already fill other roles as students, parents, caregivers, and employees at other companies than Red Hat. The D&I team's bandwidth is different than other committees with members that may participate as part of their paid employment obligations.

Additionally, the type of issues this team reviews are usually not black-and-white topics with a clear and definite answer. Often they are gray areas. I think these decisions stand to benefit from proper time to review and gather feedback. For full consensus voting, I believe 14 days protects the time commitments of team members outside of Fedora without requiring them to be more active or get pushed out of decisions. The people who are most affected by shortening the voting period are ones whose perspectives we may lose.

Metadata Update from @jflory7:
- Issue priority set to: next meeting (was: needs review)

10 months ago

Since this ticket has stalled, I suggest we vote on the following changes to the lazy approval process:

  1. Consent is assumed unless valid objections are raised within 7 calendar days
  2. Remove requesting an extended deadline in favor of only requesting a switch to full consensus voting

I am +1 to these two edits for the reasons explained in my last comment.

I don't want to be the person dragging this further but as this is very critical piece for the team, please check my comments below -

Since this ticket has stalled, I suggest we vote on the following changes to the lazy approval process:

Consent is assumed unless valid objections are raised within 7 calendar days

As you mentioned in your previous comments as well, "This team is volunteer-led. Members already fill other roles as students, parents, caregivers, and employees at other companies than Red Hat. The D&I team's bandwidth is different than other committees with members that may participate as part of their paid employment obligations."

It is very valid point and I believe that is the reason why - we should give more than a week for no objection, as any ticket may slip if a member is on a week long holidays or traveling etc.

Please consider increasing time for this one - May be 1.5 week if not more?

Remove requesting an extended deadline in favor of only requesting a switch to full consensus voting

Sorry, I don't understand this one :(
Can you please explain a bit. Thanks.

I am +1 to these two edits for the reasons explained in my last comment.

Thanks for asking these questions @amsharma.

@amsharma:
It is very valid point and I believe that is the reason why - we should give more than a week for no objection, as any ticket may slip if a member is on a week long holidays or traveling etc.
Please consider increasing time for this one - May be 1.5 week if not more?

I suggested a week only for lazy approval decisions. To me, lazy approval is useful for decisions like these:

  • Ticket #108: Pagure tag clean-up for D&I Team repo
  • Ticket #99: Create diversity project in Taiga (Fedora hosted instance)
  • Ticket #74: Publish call for mentors article on Fedora Outreachy Dec 2018 Round
    • In this case, we needed to move quickly to get the mentor call out. We needed to approve a Community Blog post. I see this as low-stakes.
  • Ticket #70: Distribution of Fedora Women Stickers

For decisions that require deeper consideration, these decisions fall under full consensus. I intended my suggestion as a compromise between both you and @bex's feedback. This way, minor, low-stakes decisions move forward quickly while important decisions benefit from full 14 days to add feedback.

What do you think? Does this address your doubt?

@amsharma:
Sorry, I don't understand this one :(
Can you please explain a bit. Thanks.

Sure. In the original proposal, anyone can request a lazy approval decision to have a time extension. However, it is not clear how long a time extension could be. If someone needs a time extension on a lazy approval decision, we should instead follow the full consensus decision model. This way, it falls under the documented full consensus decision policy. I think it is more clear and transparent this way.

Does this also make sense to you?

Metadata Update from @jflory7:
- Issue priority set to: waiting on assignee (was: next meeting)

10 months ago

I am bit lost here :(
I will try to catch-up with last comments made and make changes in https://docs.google.com/document/d/1jT_a_nVgUnIwIIn9uWmw9P3iQ0hfiVtC7qoQ1FAO03c/edit accordingly. Meanwhile if someone wants to comment in the doc, please feel free. Thanks,

Metadata Update from @jflory7:
- Issue untagged with: needs votes, new idea

3 months ago

@amsharma We left off on PR #105. There was a broken link which didn't work, that was the last blocking thing. I went ahead and merged that pull request since it has been sitting for so long and we already discussed it at great length.

Closing this ticket as complete. Any future changes to the decision-making process should be opened as a new ticket.

Metadata Update from @jflory7:
- Issue close_status updated to: complete
- Issue status updated to: Closed (was: Open)

3 months ago

Login to comment on this ticket.

Metadata