proof of concept for reviewing and landing proposed changes #1868
Conversation
paulfitz
force-pushed
the
paulfitz/proposed-changes
branch
from
ae4c698 to
b03d326
Compare
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
paulfitz
force-pushed
the
paulfitz/proposed-changes
branch
2 times, most recently
from
4a815f3 to
9faaf3e
Compare
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
|
Deployed commit |
1 participant
Context
This is a WIP for fleshing out the "crowdsourcing" idea in #1837 and #1829
In short, you can chose to collect "proposed changes" for a document by setting a flag. If you do so, then anyone can fork your document, make some changes, and propose those changes to you by clicking a button. All proposed changes to a document are visible on a special "proposed changes" page on the document. You can click to merge changes you like. BE AWARE that for now only very unambitious changes are mergeable (changes to strings and numbers), though we hope to iterate on that quickly if the feature proves useful.
How to try out the preview
See the fly.dev link posted by a bot at the end of this PR thread.
First, you must visit a document and append
?experiment=proposedChangesPageto the URL. When you do this, then on document settings you will see ... ANOTHER separate flag for enabling proposals. This flag will exist even when the feature matures. I added a flag for this because we're planning to let everyone see proposals made to a public doc, and it might be annoying if proposals could be added without you being aware of the possibility.Once you've set this flag, there is a new "Proposed Changes" page, initially empty.
If someone makes a fork of your document, they see a "Proposed Changes" page, which shows the changes they have made relative to your document, and lets them "Propose" that to you.
When they Propose, they see some status information.
And this is what you see on your "trunk" document:
The rendering of differences will need to improve! That isn't in the scope of this PR though, it is separate work. The data needed to make better differences is available, you can see more context if you click the little arrow near the table name:
You can choose to click "Apply" and have the changes show up in your doc (ctrl-Z to undo):
This isn't new, but you can click in cells in the difference to be brought to where they are in your document (in simple cases). Here I click on Gibson:
(These screenshots are out of date, just showing the first working pass through.)
Summary:
?experiment=proposedChangesPageto URL, accept the experiment.Related issues
Has this been tested?
Please don't look at the code yet, it is full of printfs and placeholders, I'll be embarrassed. Just putting this up to get a preview to show around as it matures.
TODO
Implementation details
Not much new is added to Grist. This is built on the existing forking mechanism. An extra table is added in the home db called
proposals. Each row stores the kind of results the/compareendpoint gives for a pair of documents, serialized in json. (This could get big for big changes! That would be bad. Future option: don't store content of big changes, compute it on need, or store externally). This makes the proposals page quick and easy to render. A few flags are added todocs.optionsin the home db.Since proposals aren't part of the doc, undo/redo doesn't work naturally for change operations (dismissing, retracting etc). Applying proposals can be and is made undoable through the built in mechanism, but isn't well integrated with the proposals page.