Tantek’s Thoughts 2024-5

W3C Sustainability Community Group meeting

Session description

The Sustainability Community Group (CG) identified a number of projects and work areas in its first meeting. Since then, two things key things have happened: First, the Sustainable Web Design CG has been forked off to its own in-progress Interest Group charter (on w3c-ac-members member only link) to focus on the Web Sustainability Guidelines. Thus this Sustainability CG meeting will focus on other areas listed. Second, the Ethical Web Principles (EWP) has been voted on by the W3C Advisory Committee, and there were no objections to the section on environmental sustainability, which provides an excellent forward-looking focus for a Sustainability CG meeting.

Session goal

The goal of this session is to discuss and pick a few of the Sustainability CG work areas that are most directly and actionably aligned with the EWP encouragement to “endeavor not to do further harm to the environment when we introduce new technologies to the web”, and identify goals and next steps towards those goals. For example, expanding on the Principles identified by the EWP, and how to do a sustainability (s12y) assessment of new and proposed technologies towards establishing a practice of Sustainability Horizontal Reviews to build on W3C’s existing accessibility (a11y), internationalization (i18n), security, and privacy horizontal reviews.

Additional session chairs (Optional)

No response

Who can attend

Restricted to TPAC registrants

IRC channel (Optional)

#sustainability

Other sessions where we should avoid scheduling conflicts (Optional)

#55, #59, #65, #68, #70, #77, #84, #87, #88, #89, #99

Instructions for meeting planners (Optional)

No response

Agenda for the meeting.

To be added to https://www.w3.org/wiki/Sustainability if this session is approved.

W3C Vision — Getting To Statement

Session Description

The Advisory Board (AB) published the W3C Vision as a Note earlier this year. The Vision Task Force (VisionTF) has processed most issues and a small number of Statement Blockers remain. This breakout session is an open session for working through the remaining Statement Blocker issues.

Session goal

The goal of this session is reach consensus resolutions on the remaining Statement Blocker issues for the W3C Vision, so the Vision Task Force can prepare an updated W3C Vision Note for publication as a proposed Statement for an Advisory Committee vote.

Additional session chairs (Optional)

@cwilso

Who can attend

Restricted to TPAC registrants

IRC Channel (Optional)

#vision

Other sessions where we should avoid scheduling conflicts (Optional)

#55, #59, #65, #68, #70, #77, #87, #88, #89, #99, #100

Instructions for meeting planners (Optional)

No response

Agenda for the meeting.

w3.org/wiki/AB/VisionTF/2024-09-25

Came up with and tried a three phase pomodoro technique yesterday for working thru tasks and projects. This three phase pomodoro cycle repeats and resyncs hourly. The three phases I came up with: * physical tidying/cleaning * physical processing * digital processing This worked quite well and I got a lot of things done, tasks completed or significantly advanced in ~6 hours. Many of these were “annoying” or “boring” but often not immediately “necessary” tasks that I had left undone (procrastinated) for many weeks, especially with all the travel I have had in the past two months nevermind first two-thirds of this year. I took the basic idea of a pomodoro 20-minute timebox^1, figured three of those fit into an hour, and picked three things that were cognitively different enough that switching from one to the other would use different cognitive skills (perhaps different parts of my brain), thus allowing a form of cognitive rest (rather than fatigue, and giving one part of my brain a chance to rest, while using others). This eliminated the need to take “pomodoro breaks”, whether 5 minutes or 20-30 minutes and it felt nearly effortless (actually fun at times) to cycle through the three phases, repeatedly, for hours on end. Before I knew it six hours had gone by and many tasks had been completed. The three 20 minute phases have the advantage of quickly determining at any time which phase you should be in by checking your watch/phone for :00-:20, :20-:40, :40-:00. If you happened to be “out of phase”, e.g. “run over” because you were finishing something up, rather than stressing about it, switch to the in-progress phase and pick-up a new task accordingly. A 20 minute timebox also has the advantage that tasks are less annoying or boring when you know that in less than 20 minutes you will be able to set them down and switch to something else. There was an iterative sense of expectation of novelty. The expectation of even only a little novelty was enough to make things go more quickly in the present, and even provide a game-like encouragement of see how far I can get with this boring or annoying task in the little time remaining. Could I even complete this one task in less than 20 minutes? I think repeating three phase pomodoro cycles worked particularly well on a Saturday afternoon when I had very few external interrupts. I think that was key. It gave a sense of momentum, if actual flow^2, that itself felt like it gave me a source of energy to keep going. I’m not sure it would work during normal work hours in any highly or even partially collaborative environment. Interruptions for physical needs, moving around, drinking, eating etc. were something that I allowed at any time, and that removed any stress about those too. I rarely set any count-down timers. A few times when I recognized I was starting or picking up a task that I might get absolutely lost in (such as many digital processing tasks like email), I set an explicit count-down timer for the end of the phase. These timer alarms certainly helped to give me permission to put down that task (for now) and switch, rather than feeling compelled to “complete” it which I know from experience can often take much longer, and leave me feeling more tired, perhaps even too tired to do anything else. There was also a sense of relief in knowing that even if I didn’t finish a particular task by the end of a phase, I would have the opportunity to pick it right back up in 40 minutes. Or maybe by then I would have decided to work on a different task in that phase. This three phase pomodoro technique worked well for tasks that are not very cognitively engaging (hence boring or annoying). Such tasks have low context, and thus low context-switching costs, but still benefit from taking mental breaks and resets. In contrast, any deeply cognitively engaging, thinking, or creative tasks, like inventing, coding, writing, typically have a much higher context-switching costs, and in my experience work better when you can set aside a longer block of time to allow yourself build up all the context and then joyfully explore the depths of whatever it is you’re creating. That being said, I think some creative tasks (depending on the person) could benefit from time-boxing. Like having a constraint to write a short blog post in the morning before a workout or breakfast. Worth trying such one-off timeboxes or even formal pomodoros and seeing if they help complete some creative tasks faster (or more often) over time. #productivity #pomodoro #pomodoroTechnique #gtd #gettingThingsDone #Saturday References: ^1 Apparently I misremembered 20 minutes instead of the typical pomodoro 25 minutes: https://en.wikipedia.org/wiki/Pomodoro_Technique ^2 https://en.wikipedia.org/wiki/Flow_(psychology)

✏️ I want the Read Write Suggest-Edit Accept-Edit Update Web. The consumer Infinite Scroll Web leaves us feeling empty. Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia. A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks@indieweb.social) live-tooting of the demos^1, I noticed a few errors, typos or miscaptures, and pointed them out in-person. Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat. We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment. 13 years ago I wrote^2: “The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.” Now I want the Read Write Suggest-Edit Accept-Edit Update Web. The ↪ Reply button is fairly ubiquitous in modern post user interfaces (UIs). Why not also a ✏️ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits. If the author’s posts provide revision histories, when a suggested edit is accepted, a post’s history could show the contributor of the edit. Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots? To enable such UIs and interactions across servers and implementations, we may need a new type of response^3, perhaps with a special property (or more) to convey the edits being suggested. There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki: * https://indieweb.org/edit Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem. For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons: ✏️ Suggest Edit and link it to an edit URL for the static file for the post. I don’t use GitHub static files myself for posts, but here’s an example of such an edit link for one of my projects: https://tantek.com/github/cassis/edit/main/README.md This will start the process of creating a “pull request”, GitHub’s jargon^4 for a “suggested edit”. After completing GitHub’s ceremony of entering multiple text fields (summary & description), and multiple clicks to create said “pull request”, it’ll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHub’s jargon-filled ceremonies to “Merge” or “Squash & Merge”, “Delete fork”, etc. to accept the edit. It’s an awkward interaction^5, however useful for at least prototyping a ✏️ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions. We can start with the shortest path to getting something working, then learn, iterate, improve, repeat. #readWriteWeb #editableWeb #suggestEdit #acceptEdit References: ^1 https://indieweb.social/@kevinmarks/113025295600067213 ^2 https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11 ^3 https://indieweb.org/responses ^4 The phrase “pull request” was derived from the git command: “git request-pull” according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/ ^5 “edits” in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to “Edit” and “Save”. We should aspire to Wikipedia’s simplicity, not GitHub’s ceremonies. This is post 20 of #100PostsOfIndieWeb. #100Posts ← https://tantek.com/2024/242/t1/indiewebcamp-portland → https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed