How to proceed with the process for consent decisions

[photm]

Continuing the discussion from Reviewing the process for consent decisions and Proposed Consent-decision process v2:

I think we should keep to the current process, except if we find an objection to doing so. According to the “Reviewing decisions” section, reviewing means doing another consent decision, “this time to decide whether to keep the decision or to update it.” (Actually, the wording became abit less clear regarding the formal meaning of the consent decision, so to guide interpretation: The previous version says “the secretary will start a consent decision on whether to keep the decision until the next review”) Once there’s an objection, we should of course proceed by integrating it – in the absence of an objection, we should do only minor or trivial changes (which is not strictly allowed, but we probably want it to be).

I broke the rules by creating a wiki for the review (though I was not aware that I was breaking the rules), and I’ve now come to see that it was a bad idea to do so. In order to clean up disturbances (as in the breaking agreements pattern), I would like to propose starting again with the current document, and motivating each change we make with an objection. (Concerns can be dealt with later, once we’ve made an actual decision on a version with the objections fixed.)

@wolftune I hope you feel OK with this approach – after all, you’ve spent quite some time doing the rewrite. I still think we learned a lot doing it, and this information will help us find good objections/amendments.

If it turns out that we should use this approach, we might want to start a new wiki beginning with the current document. This time, the only ways to participate would be:

• Raise an objection/concern by replying to the wiki post. Mark it with / like in a consent decision.
• Propose an amendment by replying to an objection. (Let’s ignore the concerns until the objections are all fixed.)
• Implement an amendment (that was motivated by an objection and posted) by editing the wiki post.

It would also be allowed to edit the wiki post according to an amendment that was discussed at the other threads, as long as it is motivated by an objection that seems to have everyone’s acceptance. (This way, I think we don’t lose much of the work we did so far, except for the big rewrite – sorry @wolftune )

Also pinging @smichel17 and @alignwaivers (and maybe @Salt) because they participated in the discussion. What do you think?

[smichel17]

@wolftune and I had an (ongoing) private conversation about some of the tensions I brought up, and while we’re still discussing, our current understanding is that he’s not quite done with the rewrite and one of his main goals is to make the policies easier to review. So I am going to hold off on the tension around time-necessary-to-review-stuff until he finishes. Put differently, I’m now more confident that it addresses an actual tension — mine! If this revision makes future edits less time-consuming to review, that’s a concrete improvement.

[photm]

Ok, then I guess I’ll have to wait and be convinced by the results .

My observation so far was that the bulk of the changes were adding the “Notice tension(s)” and “Describe driver(s)” sections, adding rules about tags and about inviting people, and maybe other additions. I didn’t observe an increase in readability.

“Finalizing a consent decision” has become its own section, I didn’t notice that. But this is a small change that can easily be motivated and implemented as I described above.

I’m OK with waiting, it’s just that I feel I wouldn’t consent to most of the v2 draft (for waste reasons), and I would like to be able to participate in creating a version that I would likely consent to.

[alignwaivers]

I haven’t gone through the whole rewrite, but I thought that was going in a valid direction and there was legitimate improvements. But that being said, it’s there and maybe it can be implemented or utilized at a later time (in retrospect), it’s usually no fun to have wasted efforts, I’m curious if there is a way of reconciling/salvaging the highlights (‘or best of’) the rewrite, or does @wolftune feel comfortable that the takeaways could translate to ‘objections’ appropriately with this proposal?

@photm, I appreciate the work you’ve done (and ty for pinging me). This proposal generally reasonable to me

@photm

Propose an amendment by replying to an objection. (Let’s ignore the concerns until the objections are all fixed.)

I can see how that might be a good rule of thumb, but shouldn’t always be true (the reality is some people are less predisposed to raise ‘objections’ than others, and there might be a more valid and serious ‘concern’ raised than an objection. And for it to be addressed, I supose someone could ‘upgrade’ a concern to an objection, but…

concern: starting to feel like there’s so many hard lines, it’s becoming harder to navigate, and I wish there could be a more fluid/human-feeling solution (given the online context though, this is difficult!). Maybe the caveat is - there’s always some degree of exceptions, but it feels to me like posting ‘rules’ like this are set in stone in some way? Not sure how to express this exactly, but not sure the added pressure is actually worth the functionality - hard to say until a rhythm’s been established with any ruleset, I think.

I could be wrong here, these are the thoughts that come to mind. It just seems like if it could easily get to the point of too many hardlined rules and hard enough to follow that it will be tedious/nerve to go through with more formal steps, especially for more timid folks. Seems like implementing hard-er rules gradually would be better, and erring on the side of guidelines. I’m pretty sure that’s not a trivial rephrase/reframe

[wolftune]

I don’t agree with the premise that updates require objections to existing policies. The point of an objection is to block the adoption of a policy. It’s not about later improvements. We all need to feel comfortably consenting to policies that are indeed good-enough without worries that it will be much more burdensome to later improve.

Put another way: there’s a hierarchy in how hard we want it to be to amend things. We want the Bylaws to be really solid and reasonably difficult to amend. We want the other working policies to be easier to amend, but we still want some check-and-balances. Some policies might be entirely within the domain of one role, and thus one person could just update them without any outside approval (but they could request feedback if desired).

The decision-process policy is in the middle. It’s not Bylaws level, but it’s also not something to just change without some clear perspectives.

Anyway, the whole tension brought up by @smichel17 was his reply to me posting that I had opened a GitLab issue assigned to myself to do all the cleaning up of the revised policy to capture all the various concerns (including splitting to multiple documents). There have been a large number of concerns brought up which all have value and are not addressed by the initial version.

It makes sense in general to iterate in small bits, but when a policy is new, we should expect to find a large quantity of issues and things to improve. So, I want to set these expectations going forward: the first version of a new idea is likely to lead to a revision with lots of changes as we get used to putting the new idea into practice. We do not want to do 23 decisions for each of 23 related concerns that get noticed. It’s okay to do an overall v2 edition and then get concerns and objections to a release-candidate of that. Probably after such a revision and real practice with an idea, we’ll be solid enough that we then see only minor and infrequent changes.

[photm]

I mostly agree (and have changed my mind a bit), but there’s a few places where I think I could say something useful:

@wolftune

I don’t agree with the premise that updates require objections to existing policies. The point of an objection is to block the adoption of a policy. It’s not about later improvements.

I see how this makes sense – this is basically doing decisions via “everyone can propose, everyone can object”. However, if I understand S3 correctly, in S3 objections are required for any changes (thus any piece of agreement written is based on a reason, i.e. a driver or an objection): I think Evaluate And Evolve Agreements is the right pattern to look at for this. It says:

• Is there any reason to drop this agreement?

I.e. check for objections to the driver.

• How can this agreement be improved?

I.e. check for objections to the agreement. Note that the definition of objection includes “worthwhile ways to improve it”. The pattern also says:

Evaluating agreements can be as simple as checking that an agreement is still relevant, and there is no objection to keeping it as it is.

The “checking that […] still relevant” corresponds to checking for objections to the driver. The “no objection to keeping it as it is” then obviously corresponds to the question “How can this agreement be improved?” – i.e. this question asks for objections.

@wolftune

We do not want to do 23 decisions for each of 23 related concerns that get noticed.

In S3, if we would really want to handle these as 23 separate concerns, we would do 23 decisions – this wouldn’t matter because they only cost a few seconds each. Our process is not this cheap sadly, which is why I didn’t propose to use it. I proposed to give reasons for each change, not to make a decision for each change. (This would mean not exactly keeping the rules, so sorry that the top post doesn’t make this clear.)

@wolftune

the first version of a new idea is likely to lead to a revision with lots of changes as we get used to putting the new idea into practice.

I agree that this is the case. Note that S3 does allow to do a major rewrite of the agreement, or in other words: To create a new proposal to replace the agreement. This is one of the strategies in Resolve Objections under “Defer”, namely: “Co-create a new proposal”.

The point I am making is: S3 does allow what we’re doing here. But it requires us to start with an objection, and decide that we want to resolve it in this manner.

@wolftune

There have been a large number of concerns brought up which all have value and are not addressed by the initial version.

I think this statement has the potential to turn into the objection I am asking for . You have repeatedly spoken of lots of concerns that have been brought up, but I didn’t see any which were not addressed by the edits I did at the original wiki. (Note that I referred to the objection/concern my edits were related to, in the corresponding edit descriptions. The edits which don’t refer to any were made because I think people requested the changes, but I didn’t agree that they were based on an objection/concern that was raised.)

You’re very convinced it’s worth the time to create a v2, so you probably have a reason for thinking this way. I would love to see it explained.

(Maybe only for when this situation comes up again in the future:) If we do decide to create a new version of the proposal, then how about co-creating it? I’m OK with you being the tuner (your english is likely better than mine ;)), but I would appreciate to know the list of considerations/ideas your work is based on. Via Proposal Forming you could sketch the ideas you have while also inviting input from others.

I think part of the situation is caused by not having a driver, so I’m kinda sorry I added it in retrospect and then demanded everything to be aligned with it . If the driver had been there before, you would likely have brought your additions up under a new driver – this way, the tensions your work is based on would have been very clear from the beginning.

[wolftune]

I agree with all of that. In this case (and this should be the only such case), the process itself didn’t exist for the decision on v1 of the proposal. And one of the items that came up since was the question of how formal to be in agreeing on drivers or objections before drafting any proposals. The suggestion on that since then has been to allow some trials of mixing this but still make sure to have drivers written out so they can be discussed.

For this v2, after the recent prompting, I made this updated driver at this exact reply number 16: WIP: Proposed Consent-decision process v2

It’s not an absolutely perfect driver statement, but it gets the gist. I am not suggesting that this rewrite itself demonstrate a good future process. I’m suggesting that the very tensions in following v1 and how strictly and around the approval of v1 make it such that following a pedantic process for v2 is something we should not be strict about.

I want to be strict that once we’re opening a decision on v2 that we really be sure everyone can easily understand v2 and agree with everything in it. Once that happens, we can use it going forward.

All of this, including the discussion here, involves us making sense of this very process, the ideas from v1, the issues, and the S3 concepts. And that should be informing the rewrite. I know it’s been messy, but thus the whole point is to write v2 so that we don’t repeat this very mess. In other words: I’m aiming to address all these concerns in the v2, and I want to then be sure that everyone feels they have been addressed. The idea is not to make the messy process the precedent but to have the v2 as the tool by which we avoid this mess in the future.

[photm]

@wolftune

For this v2, after the recent prompting, I made this updated driver at this exact reply number 16: WIP: Proposed Consent-decision process v2

Thanks a lot, I should really have re-read a bit before I posted… . I apologize for not listening well back then, I think I was a bit too emotional… This thread is probably the right place to reply to the driver:

@wolftune

Without the process itself in place when we developed and agreed on the first version, we had to wrap up the long and messy process to get to a starting point for iteration.

I might agree here, but I’m not sure. The process we followed in the beginning was indeed intended to produce a quick starting point for iteration. However, I thought the messiness was fixed as a result of @smichel17’s objection?

So maybe either it was not fixed well enough, or new messiness was introduced later on (as part of the review we’re doing currently) that needs to be fixed now? In the latter case, the driver should not call it “the first version”, should it?

@wolftune

Now, we need to make it easy and accessible for everyone (including newcomers) to easily read and understand the process.

From my point of view, the current process is designed to be accessible (including for newcomers). For instance,

• Instead of referring to drivers, it says “Before coming up with solutions for a problem, write about the problem on the forum and get feedback. Make sure everyone agrees it’s a problem that should be solved.” This is intentional.

• The only other S3 terms being referred to are “consent decision” (Ok, maybe that should’ve been explained), “objection”, “concern” – definitions for the latter two are given, for exactly the reason of accessibility – “integrate objections” (Ok, an explanation is needed), “review” (Obvious enough given the explanation of the process). Maybe there’s more?

• It is organized as several "How to"s and I think it’s easy enough to find the one you need in a given moment.

Maybe it only tries to be accessible, but fails? In this case, I would appreciate to see the shortcomings pointed out. Are they so numerous that a rewrite is necessary? I think I just don’t see as many shortcomings as you do, so maybe you could list some?

@wolftune

By overhauling the formatting and structure (and addressing concerns that arise while working through that), we can get a better reference which will be easy to iterate on going forward. With that in place, we will be best set to follow the process successfully on all our future decisions.

Again, I fail to see what the problems are with the current formatting and structure. I do see messiness in the current v2 draft (and I probably have my part in causing it), and I would agree that it should be fixed – maybe by rewriting. But since I don’t see the messiness in the current process, I think it would make sense to only rewrite the additional bits into new documents, mostly keeping the structure of the current document. Rationale can then easily be given for changes to the current document, and rationale for every single bit in the new documents is not necessary nor am I asking for it.

@wolftune

All of this, including the discussion here, involves us making sense of this very process, the ideas from v1, the issues, and the S3 concepts. And that should be informing the rewrite.

I agree . I think it’s kind of hard to discuss this right now, because only you know exactly what kind of changes we’re talking about. However, I’m raising it because a) this is a good time to learn about the process, as our learning will immediately influence the process, and b) the difficulty of communicating why we would do a rewrite is exactly what we need to experience (i.e. we should discuss this before everyone sees your finished rewrite and knows what you’re talking about), because we should communicate this well next time.

@wolftune

The idea is not to make the messy process the precedent but to have the v2 as the tool by which we avoid this mess in the future.

The current draft says “A review follows the same process as initial drafting but starts the wiki post with the existing agreement.” I think this is what we’re doing now, and I think we shouldn’t be doing it – neither now, nor in the future. I think we should follow Evaluate And Evolve Agreements at review, i.e.

• invite reports about what people experienced with the agreement
• invite objections to the driver
• invite objections to the agreement

Making it a wiki invites any changes people feel like making, until the situation stabilizes – by then, we might be far from consent, and will have to do all the work of converging again. If we only allow changes based on objections (and only if the amendments have consent themselves – we should fix our process in this respect too), we would save a lot of time.

My idea was to design an ad-hoc process for right now (given in the top post here), which is a much more efficient tool to arrive at the v2 we both want. At the same time, I would propose that sth at least similar to the ad-hoc process should go into the v2 itself.

After all, if an effective/efficient way to arrive at the v2 we both want is the messy process, then why not use this process in the future? Since I think we both agree that we should not use it in the future, what special circumstances make it more effective/efficient for right now?

The only reason I could see would be lost work. But we already agree it needs to be re-written and split up. I think we also agree that all the new bits belong into new documents with a different driver than the one I added recently. I think we also agree that the current process is mostly good towards that driver, except for waste that would be moved into other documents. Is there substantial mess in the current process (as opposed to the current v2 draft)? If not, the main “messy” / “re-writing” work would not be related to the current document, so why not follow a cleaner process for the current document?

[wolftune]

I agree with all that. I think there’s a lot of tension around too-many-things-at-once. But I think the messy process brought out a lot of value in the form of surfacing tensions as well as constructive proposals for improvements.

I think both the v2 draft and the discussion around it could be a valuable source of ideas what will be the effective final v2 revision. I don’t object to handling each objection bit-by-bit if it doesn’t turn into even more work. This relates to the mention of GitLab I added on the main v2 topic. GitLab has the function of having proposed changes that aren’t integrated until approved, and once approved the discussion of the change gets marked as approved. In the forum, we don’t have something quite comparable, it feels like clunky workarounds.

So, I’d somewhat want to try working with GitLab more for this. I wonder if we can find a good balance. Maybe if the WIP review etc can happen in GitLab and anyone without an account is welcome to simply view it there and then comment on the forum? I’m not sure, but GitLab is just so much better as a tool for this type of work.

Deciding on concepts is fine on the forum, but working out iterations of exact wording and such is better at GitLab.

[photm]

@wolftune

But I think the messy process brought out a lot of value in the form of surfacing tensions as well as constructive proposals for improvements.

I agree

@wolftune

I don’t object to handling each objection bit-by-bit if it doesn’t turn into even more work.

Very good to mention “more work”. Maybe we can follow the process a bit more loosely / raise objections that deal with more at once whenever we feel the extra precision / finegrained-ness would be too much work.

[photm]

@wolftune Does it make sense for you to post a driver statement for the navigating via tension + driver bits, as a wiki, and then continue as usual to create a proposal for it? (Maybe the current draft can be mostly copied/pasted, depends on whether you like the wording and what the driver will say.)

I think this can be done independently from the other changes to the process. The current process can be used as if it was only about seeking and integrating objections, i.e. the proposal for navigating via tension could look like this:

• Notice tensions etc, discuss on the forum
• Write a driver statement
• Seek and integrate objections to the driver statement, “[using this process]($link to current process)”
• Write a proposal to respond to the driver
• Seek and integrate objections to the proposal, “[using this process]($link to current process)”

The name of the “seeking and integrating objections” process might change, but otherwise nothing should break. Is this a good way to split?

I wonder what other bits we’d want to split into new documents – maybe these:

• Review (can benefit from Evaluate And Evolve Agreements): We continuously learn more about our agreements, but this information can stay subconscious. We need to apply our new knowledge to improve our agreements.
• “How to deal with invalid objections” (can benefit from Test Arguments Qualify as Objections): We sometimes make assumptions without noticing and communicating them. We need to understand and check each other’s reasoning, in order to spend our time on what helps us move forward.
• “The power remains with the team” (can be the place for more circle structure maybe): We want to operate democratically but also efficiently. We want those who do the work to be the main decision makers. We need clarity on who does which decisions, while also using the wisdom of the larger community.
• Minor changes (can be the place to document the governance repo maybe): We need our agreements to be cleanly documented, so we can focus on doing actual work.

More documents would also mean more reviews, but I think these sections clearly need their own driver statements, and should thus be reviewed individually in the context of that driver. We can still do multiple separate reviews at once if we want to.

I wonder whether we should first check for objections to splitting in general, or to splitting roughly along these lines? I tend to think we don’t need to check for objections to this, maybe because I think it’s likely that people would consent. (Sad that checking for objections is so costly on the forum…)