[06:11] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww marked [pull request #2486](https://github.com/MirServer/mir/pull/2486): Screencopy: wait for damage before copying frame as ready for review
[07:37] <Saviq> Good morning!
[07:42] <RAOF> Yo!
[07:50] <RAOF> Saviq: Hm. I'm looking at migrating the wayland-native-kiosk-snap tutorial, but it's not entirely clear from [the documentation documentaton](https://mir-server.io/docs/1how-to-maintain-mir-documentation#heading--converting-content-from-ubuntu-tutorials) how to do this.
[07:51] <RAOF> Particularly: Do we copy the content of the existing tutorial into a new post in the Mir section, and then replace the existing document with a link to the new post?
[07:51] <Saviq> I suppose I wasn't clear on what to do with the content "taken out"?
[07:51] <Saviq> This!
[07:51] <Saviq> In the Mir/Docs category, yes
[07:51] <RAOF> 🎉
[07:52] <Saviq> Feel free to improve the Docs² guide, too
[07:54] <RAOF> 👍️
[08:13] <alan_g[m]> <RAOF> "Saviq: Hm. I'm looking at..." <- What is in there that Isn't covered by the developer guide and the "Packaging a XXX as an IoT GUI" ones I'm working through?
[08:13] <RAOF> Ok. I think https://discourse.ubuntu.com/t/make-a-wayland-native-kiosk-snap/29073 is now in the right place and linked appropriately.
[08:14] <RAOF> <Saviq> "Feel free to improve the Docs..." <- Done (I think?)
[08:17] <RAOF> alan_g[m]: I think the wayland-native-kiosk-snap doc is an actual tutorial, rather than a howto; it looks to be much more discursive and goes through a bunch of "here's what you might naively do, oops! It doesn't work. Here's why..." bits.
[08:19] <alan_g[m]> RAOF: That discursion is exactly what Diataxis says doesn't belong in turorials
[08:19] <alan_g[m]> *tutorials
[08:20] <alan_g[m]> (I disagree too)
[08:46] <Saviq> > That was me, some stuff didn't turn out how I intended. Will fix in the AM
[08:46] <Saviq> It probably makes sense to end with "… application" in the navigation pane for these.
[08:50] <alan_g[m]> "Packaging a GTK3 application"?
[08:50] <Saviq> Yes
[08:51] <Saviq> If you find that confusing, maybe an extra heading would do? "Packaging applications for IoT" and then sub items "GTK3 (Mastermind)"
[08:52] <Saviq> Although not sure we need the detail of _which_ application is used
[08:53] <alan_g[m]> :done:
[08:56] <alan_g[m]> I'm still not sure we need both the "make a wayland native..." and the "Developer guide". They cover a lot of the same ground and the former needs updating. We should try to merge them.
[08:57] <alan_g[m]> Anyway, I want to do Flutter and Electron before the week is over, so I'll focus on that.
[08:58] <Saviq> <alan_g[m]> "That discursion is exactly..." <- On this. Our current content may well not fit either category perfectly. Guidance is "tutorial is for learning", "how-to is for work". We are likely to tweak the content to better fit the framework over time, as we learn. I hope we can get help from someone with more experience at some point.
[08:58] <Saviq> But the first step is to have something. We'll improve it with time :)
[09:03] <Saviq> <alan_g[m]> "I'm still not sure we need..." <- Quite likely to merge, yeah. It is/will become more evident if they're all in a single place rather than spread over Discourse, tutorials, and… and…
[09:03] <Saviq> Once we have all the content we want in /docs, we can look at what needs merging/splitting/reworking etc.
[10:04] <RAOF> <alan_g[m]> "That discursion is exactly..." <- Wait. I thought the *difference* between tutorials and how-tos was that how-tos are straight “here's how you do a thing” and tutorials are more broad “here's a guide to the sorts of things you'll see when you try to do a thing”? Clearly U need to read Diataxis more.
[10:05] <RAOF> * Wait. I thought the *difference* between tutorials and how-tos was that how-tos are straight “here's how you do a thing” and tutorials are more broad “here's a guide to the sorts of things you'll see when you try to do a thing”? Clearly i need to read Diataxis more.
[10:06] <Saviq> Yeah you need to go through Daniele's workshop… I'm told they will run again soon
[10:07] <alan_g[m]> Again?! Yeah, I misremembered that distinction
[10:08] <alan_g[m]> I got confused because we have the developer guide etc under "How to" and I assumed that was right
[10:16] <Saviq> By "you" I meant Chris, who didn't attend yet, but if you need a refresher 🤷 ;)
[14:55] <Saviq> alan_g would you be OK with removing the app names from at least the URL paths, and maybe titles as well? I feel like it's muddying waters and if we ever decide to switch to a different app, we'll need to have a redirect
[15:07] <alan_g[m]> <Saviq> "alan_g would you be OK with..." <- From the URL, that's fine. I'd like to keep the title though as they are tutorials with the steps for specific apps.
[15:18] <grayson-g[m]> I'm scratching my head trying to figure out what `mir/fd.h` does. File descriptor?
[15:19] <alan_g[m]> grayson-g[m]: Yes
[15:28] <Saviq> <alan_g[m]> "From the URL, that's fine. I'd..." <- :done:. How to guides ;)
[15:28] <Saviq> Also, did you move the others under Tutorials?
[15:29] <alan_g[m]> Yes
[15:29] <alan_g[m]> See discussion with Chris earlier
[15:29] <Saviq> To me, both the migration and doc² ones are how-tos (they're "for work")
[15:30] <Saviq> Both should be "to the point", with little venturing out of topic
[15:30] <alan_g[m]> But they are not "recipes" for a work task. They are educating to enable work
[15:32] <Saviq> The migration one isn't? The work task being the migration?
[15:32] <alan_g[m]> SHrug
[15:32] <Saviq> I can concede on the doc² one, but the migration IMO fits the how-to bill
[15:32] <alan_g[m]> OK, change it
[15:33]  * Saviq finds it confusing that the whole site isn't cached / invalidated as one… the navigation jumps between multiple versions as I traverse the site
[15:35] <alan_g[m]> +1  - also a refresh sometimes loads an earlier version of part of the page
[15:36] <Saviq> Wonder if there's a way to force it to always load anew, like through a header or something
[15:37] <Saviq> alan_g would you please record your progress in https://github.com/orgs/MirServer/projects/9 ?
[15:38] <alan_g[m]> By EOW yeah
[15:43] <grayson-g[m]> Want to run this idea by you all before I get too stuck in. If I am understanding the crash diagnostics client properly, the idea is that a customer using Frame would create a crash log in a particular format that is stored in a specific directory, and should that crash file exist, it gets displayed on Frame.
[15:43] <grayson-g[m]> So would the idea of specifying a JSON format with fields like `app_name`, `error_time`, `error_summary`, and `error_info` make sense? It would then be up to the customer to implement this when their application crashes. Additionally, is there any other information worth reporting that I haven't specified?
[15:43] <alan_g[m]> Getting back to "Wayland native": I think there is nothing worth keeping in there that isn't already in the "developer guide", the only thing is that "developer guide" is still a download.
[15:45] <alan_g[m]> grayson-g[m]: So would the idea of specifying a JSON format with fields like `app_name`, `error_time`, `error_summary`, and `error_info` make sense? It would then be up to the customer to implement this when their application crashes. Additionally, is there any other information worth reporting that I haven't specified?
[15:45] <alan_g[m]> Why complicate it? Doesn't plain text, no markup work well enough?
[15:45] <grayson-g[m]> > <@alan_g:matrix.org> So would the idea of specifying a JSON format with fields like `app_name`, `error_time`, `error_summary`, and `error_info` make sense? It would then be up to the customer to implement this when their application crashes. Additionally, is there any other information worth reporting that I haven't specified?
[15:45] <grayson-g[m]> > 
[15:45] <grayson-g[m]> > Why complicate it? Doesn't plain text, no markup work well enough?
[15:45] <grayson-g[m]> Complicating is what I do best! But sure, that works (:
[15:47] <alan_g[m]> Repeat after me: "what is the simplest thing that might possibly work?"
[15:48] <grayson-g[m]> alan_g[m]: What is the simplest thing that might possibly work.
[15:48] <grayson-g[m]> I think I've discovered my new mantra.
[15:48] <grayson-g[m]> s/./?/
[17:06] <alan_g[m]> Have a good weekend all!
[17:07] <Saviq> Same here o/
[22:50] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww marked [pull request #2492](https://github.com/MirServer/mir/pull/2492): Add .drop method to mutex as ready for review
[23:08] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww drafted [pull request #2493](https://github.com/MirServer/mir/pull/2493): AbstractShell: add missing mutex lock
[23:08] -GitHub[m]:#mir-server-  
[23:08] -GitHub[m]:#mir-server- > I haven't observed any bugs known to be connected to this
[23:24] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww drafted [pull request #2494](https://github.com/MirServer/mir/pull/2494): Add ImmediateExecutor
[23:24] -GitHub[m]:#mir-server-  
[23:24] -GitHub[m]:#mir-server- > There are contexts in which you want to do work immediately, specifically this will be useful in porting old observers to the new observer system, when in some places we want the old behavior to remain.
[23:25] <sophie-w> My surface observer PR didn't go anywhere and has now rotted a bit, so I'm taking a new tactic of PRing it bit by bit so what's left of the PR is easier to maintain.
[23:26] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww marked [pull request #2493](https://github.com/MirServer/mir/pull/2493): AbstractShell: add missing mutex lock as ready for review
[23:26] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww marked [pull request #2494](https://github.com/MirServer/mir/pull/2494): Add ImmediateExecutor as ready for review
[23:26] <sophie-w> I don't know why my PRs were getting defaulted to being drafts
[23:52] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww edited [pull request #2493](https://github.com/MirServer/mir/pull/2493): AbstractShell: refactor confinement
[23:53] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww edited [pull request #2493](https://github.com/MirServer/mir/pull/2493): AbstractShell: refactor confinement
[23:53] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww edited [pull request #2493](https://github.com/MirServer/mir/pull/2493): AbstractShell: refactor confinement