Tantek Çelik

inventor, connector, writer, runner, scientist, more.

💬 👏
  1. New issue on GitHub project “tpac2024-breakouts”

    W3C Sustainability 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 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.

    on
  2. New issue on GitHub project “tpac2024-breakouts”

    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

    on
  3. Happy #8bitday — 256th day of the year! Here’s some reasons to celebrate:

    bit = portmanteau of binary digit

    8 binary digits can represent 256 different numerical values

    8 bits are also a byte, the fundamental unit of computer storage — 'B' is for byte in 'GB' or 'TB' as an amount of memory (e.g. 24GB) or disk space (e.g. 2TB).

    The '8' in UTF-8 also stands for 8 bits.

    Beyond computer connections, there’s lots of 8-bit music and other forms of art.

    Previously, previously, previously:
    * https://tantek.com/2015/256/t2/happy-8bitday-this-year-konamicode
    * https://tantek.com/2014/256/b1/happy-8-bit-day-8bitday
    * https://tantek.com/2013/256/t1/happy-8-bit-day
    * https://tantek.com/2012/256/t2/portland-xoxo-happy-8bitday
    * https://tantek.com/2010/256/b1/happy-8-bit-day
    * https://twitter.com/t/status/3960099908

    Glossary

    8-bit music
      https://tantek.com/w/8bitday#Music
    bit
      https://en.wikipedia.org/wiki/Bit
    byte
      https://en.wikipedia.org/wiki/Byte
    Gigabyte (GB)
      https://en.wikipedia.org/wiki/Gigabyte
    UTF-8
      https://en.wikipedia.org/wiki/UTF-8

    on
  4. likes thisismissem’s toot

    on
  5. 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¹, 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², 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:

    ¹ Apparently I misremembered 20 minutes instead of the typical pomodoro 25 minutes: https://en.wikipedia.org/wiki/Pomodoro_Technique
    ² https://en.wikipedia.org/wiki/Flow_(psychology)

    on
  6. Tip: use the W3C Link Checker and fix any errors before federating with Bridgy Fed.

    https://validator.w3.org/checklink

    If you are using Bridgy Fed to federate your posts from your personal site, I highly recommend you first run the W3C Link Checker on a post, and verify there are no “red” errors (or fix any you find), before pinging Bridgy Fed to federate the post.

    The reason is that if your post contains broken links, especially broken https: links as part of an @-mention, a weird set of timeout interactions will occur between #BridgyFed and #Mastodon that will cause any Mastodon instances following your posts to drop your federated posts as if they had not been received.

    Further, those instances will also ignore any UPDATES to that post.

    More discussion here:
    * https://chat.indieweb.org/dev/2024-09-04#t1725421768496000
    More bug details here:
    * https://github.com/snarfed/bridgy-fed/issues/884#issuecomment-2327861883

    #IndieWeb #federate #fediverse #interoperability

    This is post 22 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed
    → 🔮

    on
  7. ↳ In reply to hachyderm.io user thisismissem’s post @[email protected] we’ve tracked the bug down to one or more problems stemming from having a link in a post to an https: URL that fails to resolve or times out, in the context of an @-mention.

    Bridgy Fed is attempting to fetch it and times out. When a #fediverse instance fetches the AS2 version of a post, and Bridgy Fed attempts to fetch that post’s links to construct the AS2 for the post, Bridgy Fed times out, which then likely times out the original AS2 request, so #Mastodon instances never get the requested AS2 post.

    There are multiple possible problems:
    * content authoring errors (including bad links, links going bad)
    * Bridgy Fed attempting to retrieve every link in a post in order to construct the AS2 for a post, possibly with too long timeouts, so the overall AS2 construction takes too long
    * Mastodon timing out when requesting the AS2 for a post, then giving up and never trying again (e.g. even when it receives an UPDATE for the post)

    More discussion here:
    * https://chat.indieweb.org/dev/2024-09-04#t1725421768496000
    More details here:
    * https://github.com/snarfed/bridgy-fed/issues/884#issuecomment-2327861883

    #BridgyFed #atMention #ActivityStreams2

    on
  8. Twenty years ago this past February, Kevin Marks and I introduced #microformats in a conference presentation.

    Full post: https://tantek.com/2024/044/t1/twenty-years-microformats

    Aside: This is an even shorter summary of that post from ~200 days ago, which #Mastodon readers never got due to a Mastodon #federation bug (details in https://tantek.com/t5Yo1).

    Since early 2023, here are the top three updates & interesting developments in microformats:

    1. Growing rel=me adoption for distributed verification (✅ in Mastodon etc.)
     * Wikipedia, Threads, omg.lol
    2. Proposal to merge #microformats2 h-review into h-entry, since in practice (e.g. on #indieweb) reviews are just entries with a bit more.
    3. #metaformats adoptions, implementations, iteration

    on
  9. Twenty years ago this past February, @KevinMarks.com (@[email protected]) and I introduced #microformats in a conference presentation.

    Full post: https://tantek.com/2024/044/t1/twenty-years-microformats

    Aside: This is a summary of a longer post from ~200 days ago¹, which #Mastodon readers never got due to a Mastodon #federation bug (instances returned 202 for post inbox delivery, but did not show post to followers or on local profiles, details in https://tantek.com/t5Yo1).

    I wrote a retrospective last year: https://tantek.com/2023/047/t1/nineteen-years-microformats

    Since then, here are the top three updates & interesting developments in microformats:

    1. Growing rel=me adoption for distributed verification (✅ in Mastodon etc.)
     * Wikipedia, Threads, omg.lol support
    2. A proposal to merge #microformats2 h-review into h-entry, since reviews are in practice (e.g. on the #indieweb) always entries with a bit more information.
    3. #metaformats adoptions, implementations, and iteration

    More details:
    ¹ https://tantek.com/2024/044/t1/twenty-years-microformats

    on
  10. Adventures in IndieWeb / ActivityPub (AP) bridging:

    While in general my posts are being successfully federated by https://fed.brid.gy/ #BridgyFed, most of my recent posts, and two more earlier this year, were delivered successfully to multiple #Mastodon instances AP inboxes (returned 202), however the posts do not show up if you look-up my profile on those instances (and thus followers never saw them).

    Update: workaround found: https://tantek.com/2024/247/t4/w3c-link-checker-before-federating

    These very recent posts:
    * https://tantek.com/2024/247/t2/twenty-years-microformats-shorter
    * https://tantek.com/2024/247/t1/twenty-years-microformats-summary
    * https://tantek.com/2024/245/t1/read-write-suggest-edit-web
    * https://tantek.com/2024/242/t1/indiewebcamp-portland
    * https://tantek.com/2024/238/t3/indiewebcamp-auto-linking
    and these earlier this year:
    * https://tantek.com/2024/173/t1/years-posse-microformats-adoption
    * https://tantek.com/2024/044/t1/twenty-years-microformats

    were all delivered to over 300 instances, which returned "202" codes, however none of them show up in profile views on those instances, e.g.
    * https://indieweb.social/@[email protected]
    * https://mastodon.social/@[email protected]
    * https://social.coop/@[email protected]
    * https://w3c.social/@[email protected]
    (My most recent post on all of these is the same 2024-08-25 post starting with “All setup here at IndieWebCamp Portland!”)

    Why would a Mastodon instance respond with a 202 to an AP inbox delivery and then not show that post on the local profile view?

    GitHub tracking bug in case you can help narrow/track this down or have
    * https://github.com/snarfed/bridgy-fed/issues/884

    Let’s see if this post makes it to your Mastodon (or other #fediverse) reader/client.

    Update: ironically this very post itself (with plenty of links, including links to my domain) showed up so I’m quite confused why Mastodon is dropping some posts and not others.

    Update 2: it appears all the posts that Mastodon dropped on the floor have @-domain references, e.g. to @-KevinMarks-.-com (without the "-"s). When I changed that @-domain mention to just “Kevin Marks” in https://tantek.com/2024/247/t2/twenty-years-microformats-shorter, it got delivered and shown on Mastodon no problem, with a new slug of https://tantek.com/2024/247/t2/twenty-years-microformats-shorter2.

    Something about the ActivityStreams2 that BridgyFed is generating for hyperlinked @-domain mentions is causing Mastodon to choke and fail to show the post to followers and in a local profile.


    #indieweb #ActivityPub

    This is post 21 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/245/t1/read-write-suggest-edit-web
    https://tantek.com/2024/247/t4/w3c-link-checker-before-federating

    on
  11. ✏️ 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 (@[email protected]) live-tooting of the demos¹, 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²:

     “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³, 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 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, 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:

    ¹ https://indieweb.social/@kevinmarks/113025295600067213
    ² https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
    ³ https://indieweb.org/responses
    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/
    “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

    on
  12. Had a great time at IndieWebCamp Portland 2024 this past Sunday — our 10th IndieWebCamp in Portland!

    https://events.indieweb.org/2024/08/indiewebcamp-portland-2024-8bucXDlLqR0k

    Being a one day #IndieWebCamp, we focused more on making, hacking, and creating, than on formal discussion sessions.

    Nearly everyone gave a brief personal site intro with a summary of how they use their #IndieWeb site and what they would like to add, remove, or improve.
    * https://indieweb.org/2024/Portland/Intros

    There were lots of informal discussions, some in the main room, on the walk to and from lunch, over lunch in the nearby outdoor patio, or at tables inside the lobby of the Hotel Grand Stark.

    We wrapped up with our usual Create Day¹ Demos session, live streamed for remote attendees to see as well. Lots of great demos of things people built, designed, removed, cleaned-up, documented, and blogged! Everyone still at the camp showed something on their personal site!
    * https://indieweb.org/2024/Portland/Demos

    Group photo and lots more about IndieWebCamp Portland 2024 at the event’s wiki page:
    * https://indieweb.org/2024/Portland

    Thanks to everyone who pitched in to help organize IndieWebCamp Portland 2024! Thanks especially to Marty McGuire (@martymcgui.re) for taking live notes during both the personal site intros and create day demos, to Kevin Marks (@[email protected] @[email protected] @kevinmarks) for the IndieWebCamp live-tooting, and Ryan Barrett (@snarfed.org) for amazing breakfast pastries from Dos Hermanos.

    The experience definitely raised our hopes and confidence for returning to Portland in 2025.²


    References:

    ¹ https://indieweb.org/Create_Day
    ² https://indieweb.org/Planning#Portland

    This is post 19 of #100PostsOfIndieWeb. #100Posts #2024_238

    https://tantek.com/2024/238/t3/indiewebcamp-auto-linking
    https://tantek.com/2024/245/t1/read-write-suggest-edit-web

    on
  13. Nice #IndieWebCamp discussion session with Kevin Marks (@[email protected] @[email protected] @kevinmarks) on the topic of auto-linking¹.

    I’ve implemented an auto_link function² that handles quite a few use-cases of URLs (with or without http: or https:), @-name @-domain @-domain/path @-@-handles, hashtags(#), and footnotes(^).

    Much of it is based on what I’ve seen work (or implemented) on sites and software, and some of it is based on logically extending how people are using text punctuation across various services.

    It may be time for me to write-up an auto-link specification based on the algorithms I’ve come up with, implemented, and am using live on my site. All the algorithms work fully offline (none of them require querying a site for more info, whether well-known or otherwise), so they can be used in offline-first authoring/writing clients.

    I have identified three logical chunks of auto-linking functionality, each of which has different constraints and potential needs for local to the linking context information (like hashtags need a default tagspace). Each would be a good section for a new specification. Each is used by this very post.

    * URLs, @-s, and @-@-s
    * # hashtags
    * ^ footnotes

    #IndieWeb #autoLink #hashtag #hashtags #footnote #footnotes

    Previously, previously, previously:

    * https://tantek.com/2024/070/t1/updated-auto-linking-mention-use-cases
    * https://tantek.com/2023/100/t1/auto-linked-hashtags-federated
    * https://tantek.com/2023/043/t1/footnotes-unicode-links
    * https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo


    References:

    ¹ https://indieweb.org/autolink
    ² https://github.com/tantek/cassis/blob/main/cassis.js


    This is post 18 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/238/t1/indiewebcamp-portland
    https://tantek.com/2024/242/t1/indiewebcamp-portland

    on
  14. ↳ In reply to issue 135 of GitHub project “Meetable” In addition, if an h-card lacks an icon, perhaps Meetable should re-fetch user info more frequently, in case someone just setup their personal site and then added their image later.

    One user-interactive work-around for this could be for Meetable to refetech someone’s h-card every time they sign-in, that way, a “user fix” for this could be signing out and signing back in to Meetable. Update: I see this was noted in https://github.com/aaronpk/Meetable/issues/122 already.

    Another more aggressive user-interactive work-around for this could be refetch someone’s h-card every time a signed-in user (re)loads a Meetable page, since Meetable obviously recognizes that the user is signed in (since it offers more UI options like RSVPing and editing).

    That way the UX would be:
    * signed-in user updates their h-card with a new icon
    * user reloads whatever Meetable page they are looking at
    * Meetable detects the user page reload (same URL requested by same IP within 1hr? or use a cookie to note last time page was loaded by the user)
    * Meetable goes out and re-fetches the user’s h-card

    That would feel more responsive and discoverable, since reloading a page to see an update is a very natural thing for a user to do.

    on
  15. All setup here at IndieWebCamp Portland!

    https://events.indieweb.org/2024/08/indiewebcamp-portland-2024-8bucXDlLqR0k

    Good crowd of participants from #XOXO #XOXOConf (@xoxofest.com @[email protected] @xoxo) here to work on their personal website(s), domains, or other independent social media setups!

    As encouraged by Andy Baio (@waxy.org @[email protected] @waxpancake)

    “Every one of you should have a home on the web not controlled by a billionaire.”

    If you’re in #Portland and want help, encouragement, or camaraderie in getting setup or doing more with your personal site, come on by! We’ll be having a mix of discussion sessions and create/hack sessions.

    Personal site and hack demos at 16:00 PDT!

    #indieweb #fediverse #ActivityPub #decentralized #socialMedia

    This is post 17 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/237/t1/people-over-protocols-platforms
    https://tantek.com/2024/238/t3/indiewebcamp-auto-linking

    on
  16. People over protocols over platforms.


    inspired by today’s #indieweb #fediverse #ActivityPub #decentralized #socialMedia lunch meetup at #XOXO #XOXOConf (@[email protected])

    This is post 16 of #100PostsOfIndieWeb. #100Posts

    https://tantek.com/2024/173/t1/years-posse-microformats-adoption
    https://tantek.com/2024/238/t1/indiewebcamp-portland

    on
  17. New issue on GitHub project “explainers”

    [explainers] How should an Explainer describe out of scope aspects?

    Explainers start with a description of user problem(s) to be solved. Depending on the problem(s), the boundaries of what to solve or not may be unclear, or solutions for subset(s) of the problem(s) may be significantly simpler or more practical than solutions for the full possibilities of the problem(s).

    We should document a way (or ways) for Explainer authors to explicitly communicate what they consider out of scope for a particular Explainer, either by description or specific example(s).

    For example @martinthomson noted that currencies may not meet the documented criteria for solutions for the amount explainer.

    Here are a few ways to document such out of scope aspects:

    1. A brief “Out of scope: (inline list of examples and/or classes thereof).” sentence at the end of section 1, to explicitly communicate what problems the explainer is not trying to solve
    2. A brief "Out of scope: solutions that (inline list of undesired characteristics, dependencies, or classes thereof)" sentence or paragraph at the end of section 2, to explicitly communicate what kinds of solutions the explainer is not exploring
    3. Rephrasing the out of scope aspect as a caveat of a proposed solution, and adding that to section 8 caveats, shortcomings, etc.

    A good next step here would be some amount of experimenting with adding out of scope aspects to existing explainers in this repo, then commenting on this issue with those empirical examples. If good patterns emerge, we can document them as explicit guidance in our Explainers README.

    on
  18. 👍 to a comment on issue 202 of GitHub project “rfcs”

    on
  19. 👍 to a comment on issue 202 of GitHub project “rfcs”

    on
  20. finished the Skyline 21k (half marathon) trail race in 3:39:48! (official bib time)

    Went out with the goal to have fun and try for sub-4, finished with smiles and a sub 3:40.

    Superbly run event as always by @ScenaPerformance.com (@instagram.com/scenaperformance), race director Adam Ray, and all the great volunteers.

    So many things went well. Race write-up to follow.

    Previously:
    * 2023: DNS Skyline 50k because of a bad fever from a blood bacteria infection caught in Wakefield MA (that’s whole other story, never going back there)
    * 2022: 50k race PR at Skyline: https://tantek.com/2022/289/t1/hot-skyline50k-ultra-finish

    #Skyline #21k #halfMarathon #trailRace #trailRun

    on
  21. Good W3C SocialCG telcon yesterday morning.

    Minutes: https://www.w3.org/wiki/SocialCG/2024-08-02

    Appreciate working with @[email protected] @[email protected] @[email protected] @snarfed.org Lisa a @[email protected] @[email protected] @[email protected] @[email protected] @[email protected] @[email protected]

    #W3C #SocialCG #20240802 #2024_215 #ActivityPub #ActivityStreams #relAuthor

    on
  22. Choosing Tools

    One of the biggest challenges with tools for making things, even specific to making web things, is there are so many tools to choose from. Nearly every tool has a learning curve to overcome before being able to use it efficiently. With proficiency, comes the ability to pursue more efficient use of tools, and find limitations, papercuts, or outright bugs in the tools. If it’s an open source tool or you know its creator you can file or submit a bug report or feature request accordingly, which might result in an improved tool, eventually, or not. You have to decide whether any such tool is good enough, with tolerable faults, or if they’re bad enough to consider switching tools, or so bad that you are compelled to make your own.

    This post is my entry for the 2024 July IndieWeb Carnival theme of tools, hosted by James G., and also syndicated to IndieNews.

    Criteria

    I have many criteria for how I choose the tools I use, but nearly all of them come down to maximizing trust, efficiency, and focus, while minimizing frustration, overhead, and distraction. Some of these are baseline criteria for whether I will use a tool or not, and some are comparative criteria which help me decide which tool I choose from several options.

    Trustworthy tools should be:

    • Predictable — it should be clear what the tool will do
    • Dependable — the tool should “just work” as close to 100% of the time as possible
    • Acting as you direct it — the tool should do exactly what you direct it to do, and not what other parties, such as its creator or service provider, direct it to do
    • Forgiving — if you make a mistake, you should be able to undo or otherwise correct your mistake
    • Robust enough to keep working even when not used for a while

    Efficient tools should:

    • Be quick and easy to start using
    • Be responsive, with as low a latency as possible, ideally zero perceptible latency
    • Reduce the work necessary to complete a task, or complete multiple tasks with same amount of work otherwise
    • Reduce the time necessary to complete a task, or complete multiple tasks in the same amount of time otherwise
    • Be quick and easy to shut down, or otherwise put away
    • Use little or no energy when not in use

    Focused and focusing tools should

    • Provide clear features for accomplishing your goals
    • Encourage or reinforce focusing on your tasks and goals
    • Never interrupt you when you are using the tool to accomplish a task

    Bad tools can have many sources of frustration, and nearly all of these involve inversions of the desirable qualities noted above. Frustrating tools are less predictable, work only some of the time, randomly do things because some other party directed them to (like auto-upgrade), ask you to confirm before doing actions because they have no capability to undo, or stop working for no particular reason.

    Inefficient tools take too long to be “ready” to use, are unresponsive of otherwise have a delay when you provide input before they respond, cause you more work to complete a task, or make you take more time than simpler older tools would, require waiting for them to shut down, or use energy even when you are not doing anything with them.

    Unfocused tools have many (nearly) useless features that have nothing to do with your goals, encourage or distract you with actions irrelevant to your tasks or goals, or interrupt you when you are working on a task.

    Baseline Writing Tools

    Examples of tools that satisfy all the above:

    • Pencil (with eraser) and paper
    • A typewriter (ideally with a whiteout band) and paper

    That’s it, those are the baseline. When considering an alternative tool for similar tasks, such as writing, see if it measures up to those.

    Tools I Like Using

    For myself, I prefer to use:

    Tools I Tolerate Using

    I do also use the iOS and MacOS “Notes” app notes to sometimes write parts of posts, and sync text notes across devices, both of which have unfortunately become just frustrating enough to be barely tolerable to use.

    iOS Notes (as of iOS 17.5) are buggy when you scroll them and try to add to or edit the middle of notes. MacOS Notes have a very annoying feature where it tries to autocomplete names of people in your contacts when you type even just the first letter of their name or an @-sign, when you rarely if ever want that. MacOS Notes also forces anything that starts with a # (hash or pound) sign into a weird auto-linked hashtag that is nearly useless and breaks text selection.

    There are no options or preferences to turn off or disable these annoying supposedly “helpful” automatic features.

    There’s definitely an opportunity for a simple, reliable, easy to sync across devices, plain text notes application to replace iOS and MacOS notes, that doesn’t require signing up to some third-party service that will inevitably shut down or sell your information to advertisers or companies training their LLMs or leak your information due to poor security practices.

    Similarly I also frequently use Gmail and Google Docs in my day-to-day work, and I’ve grown relatively used to their lagginess, limitations, and weird user interface quirks. I use them as necessary for work and collaboration and otherwise do my best to minimize time spent in them.

    Better Tools

    I have focused primarily on writing tools, however I have made many distinct choices for personal web development tools as well, from writing mostly directly in HTML and CSS, to bits in PHP and JavaScript, rather than frameworks that demand regular updates that I cannot trust to not break my code. I myself try to build tools that aspire to the criteria listed above.

    At a high level, new tools should provide at least one of three things:

    1. Higher efficiency and/or quality: tools should help you do what you already could do, but faster, better, cheaper, and more precisely
    2. Democratization: tools should help more people do what only a few could do before
    3. Novelty: tools should help you do new things that were either impossible before or not even imagined

    Mostly I prefer to focus on the first of those, as there are plenty of “obvious” improvements to be made beyond existing tools, and such improvements have much more predictable effects. While democratization of tools is nearly always a good thing, I can think of a small handful of examples that demonstrate that sometimes it is not. That’s worth a separate post.

    Lastly, tools that help accomplish novel tasks that were previously impossible or not even imagined perhaps have the greatest risks and uncertainty, and thus I am ok with postponing exploring them for now.

    I wrote a few general thoughts on what tools and innovations to pursue and considerations thereof in my prior post: Responsible Inventing.

    Referencing Articles

    Articles also written about this topic that reference this article.

    1. 2024-08-01 Tom Morris: A world run by tools
    on
  23. 👍 to a comment on issue 420 of GitHub project “strategy”

    on
  24. 👍 to a comment on issue 870 of GitHub project “process”

    on
  25. 👍 to issue 870 of GitHub project “process”

    on
  26. New issue on GitHub project “sustyweb”

    [charter] Custom Success Criteria for SustyWeb Interest Group and WSG Statement

    The proposed Working Group (WG) charter contains boiler-plate "Success Criteria" which though excellent for creating strictly technical specifications intended for interoperable implementations that users can choose and use, and are far more strict than necessary for the Web Sustainability Guidelines (WSG), and may instead have the unintended consequence of removing helpful guidance that otherwise cannot pass that high bar of interoperable implementations.

    Assuming that issue 105 is resolved to create an Interest Group (IG) instead of a WG, one subsequent necessary step is to define explicit Success Criteria for the WSG itself.

    The Success Criteria for the WSG need to be rewritten to encapsulate consensus goals for the WSG, e.g. having a maximally impactful WSG as soon as possible that can be iteratively improved.

    We’d like to see a broad spectrum of any and all possible sustainable web guidance in the guidelines, from known measurable highly impactful techniques, to ideas worth exploring for more sustainable adoption and use of existing web technologies. We leave it up to the editors and contributors to the charter to help define Success Criteria for publishing a WSG Statement that takes into account the goals of the WSG, and the broad spectrum nature of the WSG.

    Our hope is that an explicit Success Criteria for a WSG Statement will help guide and focus the IG, help the IG determine when the WSG Note is ready for an Advisory Committee (AC) poll to take it to Statement, as well as provide a methodology for the Advisory Committee (AC) to evaluate a WSG Note to help determine if it passes the criteria that was documented in advance.

    on
  27. New issue on GitHub project “strategy”

    [artifacts] [discoverability] Cross-link charters, their polls & results, feedback, disposition thereof, any diffs adopted & repoll results

    Problem statement: Currently it is very difficult if not impossible in some cases to discover from a Working Group charter:

    • what were the poll results that helped create that charter?
    • was there any feedback, or objections formal or otherwise?
    • how was any dissent handled?
    • what were the changes if any from the polled charter to the adopted charter?
    • was there any follow-up repolling of poll respondents and what were the results?

    This makes it difficult for W3C members, and especially difficult for newcomers to W3C, to understand the context and work that went into chartering a working group, why some things in a charter are the way they are, and a deeper understanding of how & why the working group was created.

    Proposed solution: A good way to provide transparent and historically discoverable paths to these artifacts of chartering working groups would be better cross-hyperlinking/discoverability (follow-your-nose style) explicit links from, to, and between the following:

    • Working Group (WG) charters (both current and all previous)
    • The Advisory Committee (AC) charter WBS poll (and results) that presumably approved each charter, with perhaps also links to prior charter polls that failed.
    • A brief document summarizing critical feedback (noted issues, requested changes, required (Formal Objection) changes) on each charter poll when it closed
    • A thorough document explaining how each item of critical charter feedback was handled. Charter proposals need a “Disposition of comments” similar to a Candidate Recommendation (CR) that is Proposed (PR) to transition to a Recommendation.
    • What precise changes (diffs) were made between a proposed (polled) and eventually adopted charter to handle each item of critical feedback
    • If any such changes were made between a polled and eventually adopted charter, when were the folks who voted on the proposed charter repolled with the modified proposed charter with those changes (dated permalink to modified proposed charter as of time of repolling)
    • What were the repolling responses both in aggregate (totals x for, y against, z abstain) and individually (explicit +1/-1, passive or active abstention), same granularity as the original proposed charter poll Results Page
    • When/where was the repolling result announced (permalink to email)

    cc: @ianbjacobs, @dontcallmedom

    on
  28. 👍 to a comment on issue 105 of GitHub project “sustyweb”

    on
  29. 👍 to a comment on issue 381 of GitHub project “PWETF”

    on
  30. 👍 to issue 381 of GitHub project “PWETF”

    on
  31. New issue on GitHub project “sustyweb”

    [charter] A SustyWeb IG would work better to publish a WSG Statement sooner

    Rather than a working group (WG), a Sustainable Web Interest Group (IG) with open participation would better enable the Web Sustainability Guidlines (WSG) to have a larger impact sooner, with broader support.

    Proposal: rewrite the current proposed SustyWeb charter as charter for a SustyWeb IG and provide a plan for publishing the WSG as a Note, rapidly iterating similar to how the Community Group is already iterating on the WSG Report, with the eventual goal of publishing an AC-approved W3C Statement to give it more formal standing.

    An IG would have less process than a WG. It would for example avoid things like patent-related procedures, disclosures, etc. which should be unnecessary for the WSG.

    The IG charter could also define custom success criteria for a WSG Statement that better reflects the varied needs of providing a broad spectrum of sustainability guidelines. A broad set of sustainability guidelines would better achieve sustainability goals than subsetting or restricting the guidelines to only those that pass a more precisely objective testability bar that is expected for purely technical specifications for interoperable independent implementations.

    At a high level the WSG is also more similar to the Ethical Web principles, which itself is destined (eventually) for a W3C Statement.

    cc: @ianbjacobs, @caribouW3

    on