Add approval/suggestion system

[keyserj]

Is your feature request related to a problem? Please describe. I want to allow others to suggest changes to my topics, but I want the opportunity to accept and decline changes, so that my topics do not become disorganized by people who may not understand my original intents.

Describe the solution you'd like

• visual/text diffs to easily see changes
• option 1: PR-style (e.g. GitHub)
  • can group suggestions into a PR rather than several separate suggestions
• option 2: suggestion-style (e.g. google docs)
  • simpler for those that aren't GitHub-fluent
• option 3: … either, chosen by topic owner?

UX ideas:

• Google Docs's mode component seems good for being explicit about the current mode and allowing easy switching:

Future ideas:

• could allow people who've made e.g. > 50 contributions to a topic, to have edit access, in order to avoid issues where a topic's creator goes inactive (this combined with creator ability to remove access and view history/revert changes... forking might also help address the issue)

Additional context

• without this, new users viewing someone's topic might think they can't do anything more than comment

Technical ideas GLHF... is it legal to literally put a text-version of a topic into its own GH repo?

[keyserj]

some other benefits from allowing people to make their own changes and merge back:

• this could replace miro reflection for discourse sessions (add question nodes "thoughts about session?" "thoughts about tool?")
• this could enable people to put their own thoughts down during discussion, to bring up later if someone else is talking

[keyserj]

more notes:

• if a change is made by someone else, color that change and show ✔️❌to approve
• green for add, orange for edit, red for delete
• can't just show suggested nodes/edges without multiple diff colors because that wouldn't allow representing deletions
• hmm how to represent in code? change list per user, with button to show change lists in diagram?
• probably would be ideal to have changes represented in a way that makes "view history of diagram" easy to implement

[keyserj]

PR-style does seem nice so that people can have their own version of the diagram, without having to see all the scattered diffs. Maybe something more like allowing people to create a branch, so they can have their own version? Then the topic creator can approve individual changes from any branch? The change-grouping of a PR might not be necessary... although it might be nice for seeing clean explanation of history.

[prototyperspective]

Thanks for adding in some points from the issue above. This is a really important issue.

so that my topics do not become disorganized by people who may not understand my original intents

I think this is similar to when Wikipedia decided between the open editing model and the Nupedia model where edits had to be approved. Everyone on the net knows which model has won. Articles there are not locked to only approved edits for people who do not understand the original intent of the article creator – the topic of the article should be clear by and is defined by its title. There are all sorts of problems of biased & opinionated & incomplete & censored articles (or problem trees) if the person setting it up has ultimate control over it. (This is also a problem on Kialo, not just because the public site is largely dead and many mods inactive and despite of its debate cloning feature.)

in order to avoid issues where a topic's creator goes inactive (this combined with creator ability to remove access and view history/revert changes... forking might also help address the issue)

Forking is not a solution there, it may nevertheless possibly be useful. On Wikipedia forking articles for each and every view is not allowed. There is one article and it's supposed to inform neutrally about the different views in appropriate ways. This doesn't always work well but it could and most commonly it does. It's an illusory solution anyway since people are contributing to one problem tree and not all other forks to it, for example because the original one has more watchers / contributors, better stats like views / is more popular, shown higher up in search results, and is linked from various places (internally and externally) etc. Forking may be useful to change the scope of the problem tree or similar things. I wouldn't be sure whether it's a good idea even when it's a great thing in open source software – it may be better to ensure there's one high-quality central problem tree per topic and then e.g. enable dynamically embedding one problem tree in another tree.

The problem of people blocking out valid nodes because they view things differently or have another opinion or are biased in some way (e.g. conflict of interest) and problems of that sort is at least as large as the problem of inactive mods.

I think reverts by problem tree creators should also be revertable. See this page how it's like on Wikipedia. I don't think they should always have the ability to remove access. I think it would be best if it wasn't possible anymore to turn a problem tree private once it's been made public and has been contributed to by at least 1 other user.

people who've made e.g. > 50 contributions to a topic, to have edit access

One could add various other requirements for various other permissions, similar to how it's on Stackexchange sites. Wikipedia also has a minimum number of days since registration in addition to the edit count. Editing without having to wait for approval also makes the site more engaging, fast and fun and results in far more content. I think it would need to be the overall approved edit count, not contributions to any particular topic.

As noted in the linked issue, there could be tools users can easily spot problematic changes and then undo them after the fact instead of making very sure each and every edit is constructive before it's added.

PR-style does seem nice so that people can have their own version of the diagram, without having to see all the scattered diffs. Maybe something more like allowing people to create a branch, so they can have their own version?

Wonder what you mean there. One would view the tree including one's own suggestions where it's clear which nodes/connections are suggestions and which are part of the map. Only one's own suggestions can be seen. What do you mean with scattered diffs there? Creating some kind of branching and merging doesn't make sense to me, it's not needed and would just overcomplicate things, e.g. when people continue to contribute to the map without suggestions from the other branch being added in where the other branch gets out of sync.

[prototyperspective]

It's not just about issues of the main features being inaccessible and remain hidden to new users. It's also that you can't build a map if people can only submit comments instead of creating specific suggestions on the map to approve. The site would be inactive, not have contents, and maps essentially not be contributed to.

[keyserj]

the topic of the article should be clear by and is defined by its title

As I mentioned in this comment recently, Ameliorate is also intended to support short-term, small-group use cases (that are not intended to be Wiki-like, open/thorough/official Topics), and for those, titles may assume some context is known by the small group that's involved.

There are all sorts of problems [...] if the person setting it up has ultimate control over it

This comment also discusses this, like having a different level of restriction based on the author's intention. If people want to make a Wiki-like Topic, perhaps it should follow Wikipedia's strategy for restriction, and maybe the Topic could have an easy signifier that it's intended to be Wiki-like & less biased, like a badge. But there are intended use cases where Topics aren't Wiki-like.

Forking is not a solution there

I see your points. I think for a Wiki-like topic, some way to decentralize the Topic would be best.

The problem of people blocking out valid nodes because they view things differently

My hope is that Ameliorate's usage of scores on nodes/edges is a way to reduce bias because that's an outlet for it. E.g. something can be called out as a Benefit but scored a 1 to convey that there are people that see this as a Benefit, but I think it very much is not one. I've also intended neutral Effects to be used for cases where positive/negative is very much arguable, then hopefully more-agreeable Benefits/Detriments can be created by that Effect.

(I realize people can still abuse the node types if they are biased enough though)

See this page how it's like on Wikipedia

Nice article. I think your suggested restrictions here make sense, to basically allow a Wiki-like Topic to be decentralized.

One could add various other requirements

More good ideas, good to be aware of. I think at some point I'll probably want to make a separate issue to organize the ideas for approvals that are specific to Wiki-like topics, because there are a lot of possible features there that will likely not be added in the initial approvals implementation.

What do you mean with scattered diffs there?

I mean specifically for when groups of changes make sense. E.g. convert these two Causes and one Detriment into Subproblems, and add their own additional Causes/Detriments. These things would all give approvers more context if they were reviewed at once, rather than as separate changes.

Potentially all suggestions from one user could default to being grouped, but then that would be confusing if 5 changes are related to each other, and 5 are scattered/unrelated (e.g. fix typo on that node, add question to this node, create extra Detriment over there).

There's a tradeoff between complexity and clarity here. Larger topics would probably have this problem more. Ideally I think people could make the tradeoff themselves based on how complex their topic is.

when people continue to contribute to the map without suggestions from the other branch being added in

I think if branches were implemented, they would have to be easily visible to others, and I don't think they'd be nearly as long-lived/numerous as code branches because diagram changes seem generally less complex than code changes.

It's also that you can't build a map if people can only submit comments instead of creating specific suggestions on the map to approve

Yeah good point, that would be impeding/more effort on the authors/more room for miscommunication to convert comments into suggestions.

[prototyperspective]

Thanks for explaining. Just addressed the short-term and/or small-group use cases elsewhere.

These things would all give approvers more context if they were reviewed at once

Reviewers would see (at least in some review view mode if there is one) all suggested changes and nodes; the context is made clear by how these relate to each other on the map. So if a person suggests a whole chain of nodes these are already each in context. The reviewer can e.g. review changes in one part/region of the map at a time. Grouping the changes somehow is not really needed. At some point there could be some review guidance tool that jumps from one node that has changed after reviewing to the node that has been changed/added closest to it so you only need to press next. Grouping by user also wouldn't be useful in general there probably as the nodes at an entirely different region of the map are not necessary context of a node changed/added by the same user at an entirely different region.

that would be impeding/more effort on the authors/more room for miscommunication to convert comments into suggestions

That but also many other things, mainly that it defacilitates contributing. You can't suggest things directly etc etc. Most who would make some suggestions on the map would make far fewer or no comment that suggests this change. It's also extra burden on the map reviewers/mods. If people could only make change suggestions for Wikipedia articles on the talk pages, there would be far fewer contributors, far less content, and far fewer constructive changes per editor. It's the same here: enabling people to make suggestions makes it clearer for everybody what is meant or why it's relevant etc but it's also kind of needed for people to use the Web3.0 site.

[keyserj]

the context is made clear by how these relate to each other on the map

This is a good point and would certainly help, but I feel like there may be cases where this might not be sufficient. Though it's a bit hard to think about without actually running into them.

Grouping by user also wouldn't be useful in general

A case that seems hard to deal with, if changes aren't grouped by user: user 1 suggests adding Benefit to Solution Component, but user 2 suggests removing Solution Component. This doesn't seem like something that can clearly be visualized if changes aren't distinguished by user somehow.

That but also many other things

All good points

[prototyperspective]

I don't see why it would be hard to deal with: the solution component doesn't disappear when a user suggests removing it so the suggested added Benefit would still be there for all reviewers to see. If the solution was declined then the benefit underneath it would also be decline (and the user probably be notified somehow so could resubmit it elsewhere if it wasn't moved by some reviewer before the solution was declined). There is distinguishing by user, e.g. the username displays somewhere in the suggestion, just no grouping by user (or not early on or/and if it is developed I don't think it would be used much and mainly only for removing problematic contents which could better be done from the user's contributions page or something as these suggestions may be across many maps).

[keyserj]

the solution component doesn't disappear when a user suggests removing it so the suggested added Benefit would still be there for all reviewers to see

It seems like this would be confusing for reviewers though, to see conflicting suggestions at the same time. Just one seems annoying but imagine a string of suggestions by User 1 that all conflict with a string of suggestions by User 2 - it could get really chaotic.

I thought of another example - both users could change the same node's text in different ways, or even 3 or 4 users. That seems really confusing to visualize at one time.

[prototyperspective]

But they don't check the suggestions in real-time / live. Or do you mean contributors could make the same suggestion multiple times – I don't think that's a problem...just some additional nodes to display and it would probably only happen rarely. Ah okay, that example helped – so per node the changes would need to be grouped by user so if four users each modify a node three times then on the node one could see four different suggested versions, one per user (I don't think their edit history needs to be displayable when it comes to changes before the node has been added in). Nevertheless – and maybe I just don't understand it – I don't see use in grouping changes by user at the full map level (e.g. for the changes feed). There each diff (or merged-diff of multiple changes by one to one node) would only have the user ID.

[keyserj]

I don't see use in grouping changes by user at the full map level

I think this comment on the history issue clarified our difference in understanding "visual diffs" https://github.com/amelioro/ameliorate/issues/371#issuecomment-2484688692. I think when this is closer to implementation, I'll make sure we have a visual so it's easier to get on the same page about it and flesh it out a little more.