Currently, the rules for changing anything about a proposal once a consent decision is started, are explained under “How to integrate objections”:
Once there’s a good amendment: Edit the proposal and start a consent decision on the new proposal as described above.
In other words, if you change something, everyone needs to consent freshly. This includes objections for which the fix would be a very minor edit. By implication, it includes concerns (weaker reasons for change) for which the fix would be a minor edit.
You can, however, if you judge that the change is minor and people would surely consent to it, simply edit the proposal. If you do so, also reply to the proposal to explain which change you did. In that reply, @mention the people who already consented to the proposal. For example, you could say “@a@b@c already consented, but I’m sure they’re OK with this.” (Minor changes may also be made in the absence of objections. They may also be made to the documentation of agreements that are already decided.)
=== Consent decision ===
Are there any objections / concerns to the above? (Let’s take 7 days for this.)
This seems overly wordy and puts a lot of reliance on the person editing to know what is or isn’t going to be acceptable. Often there’s a phrase used for things like this, something akin to, “Changes which do not change the substance of the proposal may be made without interrupting the consent process.”
Generally like the idea though, thanks for proposing!
tl;dr: Minor edits to a draft {should be notated in some way such as with these brackets} to indicate a change made (and be easily reviewable by folks who had previously agreed)
I agree that it
but I’d be concerned if a minor edits weren’t obvious enough (we can’t ‘diff’ here after all)
Maybe an inbetween here would be to notate any changes from a draft that has been voted on at any time {in brackets} or something like that?
Not seeing an immediate clearcut solution but I’ve already seen how it could be a rather frustrating issue: considerations for what is a
is already
While I don’t see this coming up too often as a serious red flag for anyone (aka a disagreement about the magnitude of a minor edit)… I’d say at a minimum any ‘minor’ edits need to be very clear
This issue has already come up especially, with concerns of the timesuck required to go over every edit. Seems like checking a proposal twice is a reasonable amount for folks deciding to vote: At the time they choose to vote and at the time of ‘acceptance’ which would just require a skimming over to see the modified bits (again which should be clearly marked so as to prevent wasted time by people looking at multiple posts or the revision history.
isn’t wild but I personally don’t want to do that after every minor edit (of which there might be a few. It seems overly tedious to track every change and the relevance to every person ‘by hand’, so to speak - (but if built into a tool, then hell yeah)
I think we assume good judgement about minor edits, and leaving changes marked clearly would satisfy needs here
P.s. thanks for pointing out the breaking of this rule ( guilty) and bringing this up as a topic @photm - the fact that minor edits have been assumed to be okay by multiple parties demonstrates how much we need this ‘minor edit’ addendum
yes we can, it’s a feature for any edited post to review the edit history
This seems too burdensome in that it takes real cognitive energy to process a change and think about what it used to be if the change is fixing a typo or changing capitalization. I’d rather rely on a stated summary of the changes and check the diff if I really want to investigate.
if the change is fixing a typo or a capitalization - sure that’s trivial, but anything between trivial and a major change (what constitutes a ‘minor change’ might merit a discussion)… But let’s say there are multiple minor edits since the first that I accepted (let’s say 3). Is there a way of ‘diff’-ing between a specific post and the most recent? (i should have specified this is what I meant previously) I wouldn’t want to look through multiple versions of a post just to discern what all the differences were and I don’t see a way of doing so in discourse, but maybe I’m missing something
seems like more work to me but that’s just my opinion, especially if it’s a long post, and you wanted to see a line change more in context - if context is important, you’d need need have an inclusive quote in the summary, or make reviewers find it in the original post, etc…
but if an edit is being made then adding two characters to encapsulate the changed areas seems really simple to me.
But a summary is reasonable, it just seems like reducing efforts necessary here would be ideal, and makes ‘proposing’ a bit more daunting (when this probably will happen a lot, especially as more people join and give more input, minor tweaks will be prevalent)
Trying to imagine an ideal here: perhaps a good workflow would be some sort of merge request to the original (allowing the author to approve edits) or something like that
It doesn’t seem crazy to consider making most decisions as actual changes to the git repo as WIP MRs in Gitlab. Then, that interface can be used to really see any changes clearly. We reference or quote the change here in the forum.
The fact is, GitLab and git are more designed for handling this sort of workflow and have good ways to do reviews and mark reviews as completed etc. But Discourse has better tools for more-human discussion.
I was speaking theoretically, but yes it wouldn’t be that much work to put them in gitlab. However, it is an extra step, and I’m not confident costs are worth the benefit. People not comfortable in git wouldn’t gain the benefit, and I’m not sure it would actually save time (or have enough cases in which it would as it would require getting off discourse, etc). I still stand by bracketing changes and allowing people to look at the revision history if necessary.
There’s still a question of what a minor edit could mean, and I think it would be something along the lines of what Salt was saying, but I will make a minor edit
I put in the {significantly} to iterate my idea, but even with that sort-of redundancy, it’s a vague statement to make - thereby, it leaves the load on the author/editor of the proposal. This is why I still think minimizing the work necessary to propose (and the followup implied) seems relevant to all this.
I think a) we need to better define what “minor” means, b) much of this discussion (git vs {} vs summary vs nothing vs anything else) will be much easier to have once that is defined.
IMHO the canned-reply change was not minor (because it changes the very nature of how we implement the process), while the other two (“review date”, “capitalization & spell out S3”) were.
“The substance of the proposal” might (does it?) sound like it is related to the amount of text changed, while a very small change can be very major.
How about “doesn’t affect the implementation of the proposal”?
We’re still doing the consent decision above and noone has objected yet, so to clarify it a little: I mentioned the following post as an example of breaking the rules:
In fact, this wouldn’t keep the new rules either. According to the proposal, I would have needed to mention sth like “I capitalized a few words and expanded S3 to ‘Sociocracy 3.0’”. Rationale: This way, @Salt would have been able to judge from the notification email whether it was worth the time to review the change or not.
I’d agree that “trivial/editorial” change should be fine with maybe only a tiny notice like:
EDIT: trivial/editorial changes
I think minor changes should live in a fuzzy area where it’s okay to make changes as long as the system retains the history.
I suggest we should be wary of too much early-optimization. We’re already making great progress by having a clearer process. I worry that too much process will discourage positive iteration because we’ll hesitate to deal with much hassle for a minor change isn’t really important. I think if we never have any conflict or push to revert to a previous version, we won’t know if we’re being excessively cautious and losing value. It’s okay to have push and pull to discover where the lines need to be drawn. As long as reversion is available, it’s not that dangerous.
Trivial changes (fixing typos and formatting) should be allowed without any additional hassle
If many minor changes are made, reviewing them using discourse’s diffs might become difficult – @alignwaivers proposes to mark changes with {curly braces}, but there’s no consensus about that
Discourse’s diffs are suboptimal, but using git/GitLab would be less integrated and not everyone is familiar with git
According to @wolftune, the current proposal is a bit too much process / too safe to learn much from it.
I object to the current proposal because typo/formatting fixes should really be allowed without pinging people. Plus, if it’s under “How to integrate objections”, this suggests that changes which can prevent unintended outcomes etc can be minor – I don’t think this is what we mean with minor, so it should get its own section. While we’re at it, we can also improve the wording. I’ll make this post a wiki so we can co-create a new version of the proposal:
The following changes can be made to proposals/agreements at any time:
Trivial changes, i.e. typo fixes or changes in formatting
Minor changes, i.e. small changes that don’t impact the implementation of the agreement. If you make a minor change, also post a reasonably precise statement of the change you did.
I added the section to the wiki-post at Reviewing the process for consent decisions, as I think we will have less merge problems that way. Any further changes should be made over there.
This also removes the need for a separate consent decision.
Proposal:
/ concerns 
to the above? (Let’s take 7 days for this.)
guilty) and bringing this up as a topic 
- the fact that minor edits have been assumed to be okay by multiple parties demonstrates how much we need this ‘minor edit’ addendum