Moving keymap discussions to Github?

[RDMurray]

Hi @ScottChesworth @Justinmac84 @GarthHum @dgl1984 @GianlucaApollaro and anyone else interested in discussing keymap changes.

Should we officially move issues with the keymap to Github?

• The Whatsapp group has been very quiet for quite a while
• there really isn't any way of looking back to see what has been discussed without listening to hours of voice messages.
• Github issues would allow us to organise discussions and keep track of what has been resolved.

I'm not suggesting that we get rid of the Whatsapp group,Just that an issue should be created here for every suggested change.

[ScottChesworth]

You're one step ahead of me. Was gonna post later today in the WhatsApp group saying that key map stuff is moving here. I'm thinking that a monthly issue is probably the way to go. I'll open an issue on the first of each month, we bat around changes in the comments keeping the topmost post updated as a summary, then aim to merge on the last day of each month. I'd prefer that over individual issues just because I think it'll be easier to have current activity in one place, but am open to one issue per change too if there's something I've missed.

[LeonarddeR]

It would be very helpful if we could get some more public insight into how this process is happening indeed, so I dig this suggestion. There are several issues with the send to keymap crew label to begin with.

[ScottChesworth]

My plan for Feb's issue is to resolve loose ends from the WhatsApp group and address what's labeled here, merging those changes no later than Feb 28th. If we can stick to that monthly schedule, it'll also help adoption, people will know it's worth updating their OSARA at least once a month. I can summarize the activity in the support groups for the first few months, just to burn in that schedule.

[RDMurray]

@ScottChesworth The only problem I see with grouping issues together like that is that the thread could be a bit messy if there were several unrelated changes being discussed in the same thread. A compromise could be to have a task list in the first comment which links to individual issues that are being considered for that month's updates. I can also see a situation where the discussion of a requested change would take more than one month to resolve. I'm not suggesting rigidly having a separate issue for each change, just those that require more time to discuss.

[ScottChesworth]

Multiple issues sounds more complicated to me than just being disciplined about tackling one topic at a time, but I trust your judgement. are you up for managing the first couple months so we can see what you're imagining working in practice?

[RDMurray]

I'm happy to help manage it, yes. I'm not at all opposed to having a monthly discussion thread about which changes should be made. Just suggesting the use of a task list to keep issues organised. I think users are likely to create a new issue for each idea they have anyway. We can add the good ones to the task list for the current or next month.

[ScottChesworth]

Ok cool, can you open the task list for February tomorrow then, formatted however you want it? Here are three longstanding things we can tackle during Feb, starting from highest priority IMO:

1. Incorporate delta solo toggles.
2. Find a home for loop segment scrub.
3. Resolve as many open issues with the sent to key map crew label applied as we can. They're all gonna be things that I either didn't get around to, didn't get resolved or the resolution didn't get documented/carried back over.

At this end, I'll be attempting to sift through loose ends from the group and adding them following your format. I'll also let the group know we're moving tonight, baring the brunt of their displeasure if needs be (it's always fun being Mr Popular). :)

[jcsteh]

I'm with @RDMurray on this. I think having longer discussions in separate issues keeps things organised without the need for discipline on the part of anyone contributing; it just happens implicitly. That way, the meta issue becomes an executive thing - here are the things we're addressing and how we're addressing them - rather than a sprawling series of unrelated justification. That said, this could get messy if we have too many interdependent changes, so we'll need to monitor that.

[ScottChesworth]

Maybe some new labels to help keep track? Something like: "key map proposal", "key map change in progress", "key map held" (apply when a proposal will be address in a future round of revisions). "key map resolved", Those should cover most eventualities, I reckon?

[jcsteh]

I think we do need key map proposal. We may not need the others though:

• An in progress change will be referenced from the meta issue and you can see cross-references in the referenced issue.
• Resolved issues will be closed when the PR gets merged.
• Held issues will be still open at the time we are opening a new meta issue, as well as being not referenced by any prior meta issue.

[ScottChesworth]

Gotcha. Guess I'll just need to use a meta issue for a bit to get to grips with it.

[jcsteh]

There's also a possibility our approach won't work out and you'll get to say "I told you so," signing off as Smug Chesworth. Time will tell.

[mattymc2]

Hate that guy 😘

Sent from my iPhone

On 1 Feb 2022, at 8:45 am, James Teh @.***> wrote:

 There's also a possibility our approach won't work out and you'll get to say "I told you so," signing off as Smug Chesworth. Time will tell. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[ScottChesworth]

Pfft, nobody believes you, @mattymc2

[jcsteh]

I do love the way @mattymc2 just lurks around here, periodically popping in to offer his $0.02 of golden wisdom. :)

[RDMurray]

Is there a reason that all the current labels have no spaces in their names?

[ScottChesworth]

I do love the way @mattymc2 just lurks around here, periodically popping in to offer his $0.02 of golden wisdom. :)

Speaking as someone who's dabbled with deeper integration, I'll agree that this amount of @mattymc2 is the balance. :)

[jcsteh]

Having no spaces makes them easier to search for; e.g. you can type: is:open label:needsReaperFix into the issues search box. Otherwise, you have to do: is:open label:"needs reaper fix" which is kinda ugly. That said, I might be convinced to change if you have a strong case for it.

[RDMurray]

That makes perfect sense. I didn't want to change it, just wondered why.

[RDMurray]

Should we add all open key map proposals each month, or just those that are definite? E.G. #211 has been open for quite a while without a conclusion.

[ScottChesworth]

I reckon start with stuff that's definite for now, just to get acquainted with how this is gonna work and make sure we're tying up loose ends left from the group. If we resolve those early ish in the month, we can start bringing in stuff that still needs some thought/debate.

[jcsteh]

I'm loving the format of the summary comment in #667. That's going to mean that making the changes and writing the commit message is very straightforward.

Should we close this issue now that we've taken the plunge?

[ScottChesworth]

I gots one question before we close this. Any thoughts on a testing strategy? Do we just encourage people who are interested to make the proposed changes for themselves, or do we want to roll out test builds at some point during the monthly cycle?

[jcsteh]

Interesting idea. Perhaps towards the end of the month(when? a week?), a pull request could be opened with all the changes so far. Users could test builds created there. If consensus says all good, we just merge at the end of the month.

[ScottChesworth]

Any objection to splitting the month down the middle? First half for collecting changes, latter half for testing. I'm thinking that the longer testing period might give folks more of a chance to propose alternatives if necessary, and perhaps the extra week of testing will mean more input, clearer consensuses.

[RDMurray]

Sounds fine to me. BTW I'm working on a python script to sort the keymap file into a deterministic order, which should make the diffs smaller and hopefully almost readable. I have the script complete, but just haven't tested several keymap diffs with it yet.

[ScottChesworth]

I'm working on a python script to sort the keymap file into a deterministic order, which should make the diffs smaller and hopefully almost readable.

Acceptance of the almost readable has been my coping strategy in every post-gig WhatsApp chat with @mattymc2.

[mattymc2]

You love it

Sent from my iPhone

On 4 Feb 2022, at 10:13 am, ScottChesworth @.***> wrote:

 I'm working on a python script to sort the keymap file into a deterministic order, which should make the diffs smaller and hopefully almost readable.

Acceptance of the almost readable has been my coping strategy in every post-gig WhatsApp chat with @mattymc2.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[jcsteh]

Nice. I often wondered whether we could get away with sorting the key maps, since they're basically just key/value pairs and order shouldn't matter, but I was never able to find the time to try it and verify it didn't break things.

[RDMurray]

The format is mostly documented at Ultraschall Internals Documentation

Here are the sorted key map files for testing: Windows, Mac.

[RDMurray]

encouragingly, the output from help/ Key bindings and mouse modifiers is nearly identical, only ctrl+home and ctrl+end swap positions.

[RDMurray]

I think we can close this now and continue discussion in #667 .