I'm mostly borrowing @Martin's intuition from this comment: Place 'edit' and ‘remove’ functionalities within the same menu tier · Issue #6280 · OpenRefine/OpenRefine · GitHub. Since these are common operations I could see it being well-received to have them at the top level.
From a contributor perspective, I would also like to have clearer guidelines on when/if work might be released or reverted. That's a different and probably larger/longer-term discussion though.
I’ve looked at the feedback both here and on GitHub. I count at least four other people on GitHub explicitly supporting the new column menu change with valid UX arguments in the discussion, so we shouldn’t overlook that signal when tallying feature support.
On the flip side, the main argument against the change that’s emerged so far is around muscle memory rather than fundamental usability issues.
In terms of release cadence, we generally aim to cut a point release within five weeks after a major release, so there’s room to iterate if needed.
Given that, I think the current menu layout can go into 3.10.0 as-is. We should include a link to the forum poll in the release notes and invite broader feedback (the forum thread may need to be updated to provide a bit more context on what the pool is about). If we get strong signals that users want to revert or adjust the layout, we can plan to address that in 3.10.1 as part of the regular point-release cycle.
I’m ready to record the video presentation for OpenRefine 3.10. Before doing so, I’m waiting on the final decision regarding the placement of the “edit” and “remove” functionalities in the same menu tier (issue #6280), so the video accurately reflects the final UI included in the release.
I would prefer to go with consensus-based decision making, but I think we need to make a decision and move on. Since both Jan and Esther have chimed in recently, increasing the majority for the status quo, I propose we go with that and I'll put up a PR to revert the change which is currently in the beta.
Rory - are there any other visual/functional things pending for 3.10 which would affect Martin's recording?
Tom
I agree that at this point it seems like there's enough community support to revert the change and think of another approach to making these actions more convenient. That said, I think it's worth having a longer-term discussion about how we as a group want to think about UI evolution.
I'm not aware of any additional visual/functional changes that would impact a demo recording.
That works for me. I can start recording as soon as a new beta release is available with the PR reverted. Thanks
Great. I've merged the PR to revert the change. GitHub appears to be having issues but I will release a second beta once those have cleared, hopefully either later today or early tomorrow.
In addition to the menu change, I plan to include any merged PRs tagged with the 3.10 milestone before releasing the next beta.
3.10-beta 2 is now released! Release OpenRefine 3.10-beta2 · OpenRefine/OpenRefine · GitHub
Here is the link to the presentation video. The video is 13 minutes and 33 seconds long.
If this works for the group, I can host it on Wikimedia Commons, and we can attach it to the release notes, similar to what we did for version 3.9.
I think this is a great video!
Thank you so much! This video is such a timesaver 
. Especially as 3.10 introduces some UI changes the video greatly emphasizes their impact on UX.
The ending however was a bit abrupt...
Thanks for the video, Martin! I think it looks good. I haven't seen any new PRs to merge into the 3.10 branch so I think it makes sense to move ahead and release 3.10.0. Once the presentation video is in on Wikimedia Commons I'll create the release and add the video to the notes.
@Rory, the video should be online later today or tomorrow at the latest.
that was faster than anticipated - here it is File:OpenRefine3-10-presentation.webm - Wikimedia Commons
Great! I will release 3.10.0 later today.
It's here! Thanks for everyone's time and dedication and patience for getting this released.
Thanks! I've regenerated the release notes using 3.9.5 as the base for the diff ("Auto" probably used 3.10-beta2) and done a light editing pass to remove administrative stuff like README updates, add/revert pairs, etc. I also made the editorial decision to exclude all dependency updates. They are still available in the full change log.
I'll try to do some additional copy editing to order things by importance, consolidate multiple PRs which are part of the same feature/fix, add additional relevant details (e.g. which new Apache Compress formats we support), etc. Ideally we'd do all this before publishing the release, but the way our release workflow is currently set up doesn't support that.
Tom
I went ahead and moved some changes around, a few should probably be merged and rephrased as well.
I removed
- move rename and remove column one menu up by @smierz in move rename and remove column one menu up by smierz · Pull Request #7145 · OpenRefine/OpenRefine · GitHub
from the changelog as this was reverted
Thanks both. Unfortunately, there isn't very good (ie any) revision control on that doc. I had removed the column remove change and made a few other edits like pointing to the separate geo extension repo, adding in the new compression formats, etc, but those seem to have gotten overwritten in a read/read/write/write cycle. While I tried to be quick, I forgot to think through that the quickness would be negated by someone else's long running edit session.
Let's try to coordinate on this thread for future edits. I'll leave it alone for the next couple of hours to allow evening European access, then take over from there for an hour or two, unless folks have other suggestions.
Tom