ran the Spartan Turkey Trot #5k #race in 31:11 (MV CA, 8°C). my 2nd fastest on the @SpartanTurkey5k course, and first #turkeyTrot in 4 years! A pleasant surprise. niece(11) crushed it in 23+min, nephew2(14) in 29+min, dad in 38+min. #turkeyTrot2021
Arrived early at Mountain View High School to do a warm-up, my first “proper” warm-up before a 5k. ~10min moderate steady running, a 1min intense push, then 4x 30s strides, and walked it off.
Found my dad, niece, nephews and waited in wave 2 only a few minute before we got started.
First mile felt a lot stronger than any flat road mile I’ve run in quite some time, at least a couple of years. Passing the 1 mile marker at under 10 minutes felt really good. Paced slowed a bit, but still passed the 2 mile marker at under 20 minutes. That’s when I knew I had a chance at a 31-something time. Tried to keep pushing in the last mile or so, and it went faster than I expected.
When I reached the track for the last 300m, all my Kezar training kicked in. Gradually picked up the pace until I kicked as hard as I could on the final 100m straight, passing several, not being passed by anyone.
Stopped my watch after crossing both timing strips after the finish arch: 31:13. Official result: 31:11 (updated) Feels like with some training I could get a sub-30 next year.
since the US & Europe switch DST on adjacent weekends, a well planned trip can skip weird DST-change ∆1hr effects* inside larger timezone shifts.
there’s still winter “standard time” sunset before end of workdays and its problematic effects** (<17:00 here, and most of the U.S.).
one possible solution, for those who have the option, is to set a 16:00 end to the workday. e.g. change your "Working hours" in Google Calendar to end at 16:00 to at least discourage meetings after that: https://calendar.google.com/calendar/u/0/r/settings
Preparing for, speaking, facilitating, and participating in virtual TPAC sessions a second year in a row was very draining. Despite that, I thought the sessions went fairly well overall.
Most passionate and contentious was the session on sustainability, especially regarding what we should (or should not) do @W3C. There was a lot more alignment on the seriousness and urgency to act than I expected, and I was pleased to see that.
There was a lot of support for figuring out how to establish Sustainability as an aspect of Horizontal Review of all technical specifications, as important as Accessibility (a11y), Internationaliation (i18n), Security, and Privacy. This would likely require an explicit Interest Group, with a charter, discussed and voted on by the W3C’s Advisory Committe (AC).
Our shared sense of urgency made it clear we needed to start something sooner rather than later. A Community Group (CG) makes the most sense in the short term, chartered to work on both immediate horizontal review and the establishement of a more official Interest Group.
I created a #sustainability channel on the W3C’s Community Slack instance for informal discussions to get a Community Group started.
↳ In reply to issue 1077 of GitHub project “bridgy”Most important here is Bridgy backfeed support for existing discussion posts on GitHub, similar to the backfeed support for responses to GitHub issues.
Bridgy Publish of a "discussion" post would be great too, should that be a separate issue / feature request?
In
Bridgy backfeed documentation it says "Bridgy detects and sends webmentions for … GitHub comments and emoji reactions on your issues and pull requests" which would seem to imply that Bridgy does not yet send webmentions for emoji reactions (reacjis) on POSSEd comments on GitHub issues and pull requests, e.g. the reacjis on
this comment POSSEd by Bridgy.
According to
GitHub API docs: List reactions for an issue comment
it looks like this information is available in the GitHub API. It would be great if Bridgy could add support for backfeeding reacjis on POSSEd comments! Thanks for your consideration.
RSVP yes to: an IndieWeb eventattending @IndieWebCamp Create Day (today!) and working on my personal #openweb site. This week’s @W3C #Instagram & #Facebook #outages were a good reminder to cook what we want, and eat what we cook.
↳ In reply to issue 282 of GitHub project “strategy”Mozilla also prefers the W3C Software and Document license for working group charters, and we have been consistently requesting this license whenever charters are updated.
And as https://GitHub.com/harrybr is quoted: “during the Workshop by Professor Harry Brignull, while the term “dark pattern” (originated and popularized in part by Brignull) has been useful for marketing and raising awareness, it would be both “vague and sloppy” if used as a legal term or standard.”
That being said, “harmful patterns” is vague and dilutes the intent of this issue.
It’s also not strictly accurate from the perspective of a company implementing such patterns, from their (typically attention/growth/profit-maximizing) perspective, such patterns are helpful to them personally, their shareholders/investors if any, and not harmful.
Such patterns are also too easy for such companies to hide behind a vague "intent" of supposedly "helping" people connect (quiet importing of contacts, suggesting joining radicalizing groups), or "helping" people get products they want/"need" (deceptive marketing, creating fear/insecurity in people’s minds then selling them a product to cope), etc.
More precise (and preserving of intent, meaning, and literal effect) would be the phrase “manipulative design”, also used & recommended by that ccianet workshop (same link): “Rather than employ the terminology of “dark patterns,” these comments will refer to “manipulative design” practices or interfaces”.
↳ In reply to @stop’s tweet@stop same friend, same. Maybe we could even do an easy run/walk/chat sometime (saw "Wanna-be runner" in your bio, and tbh often still feel that myself)
