tantek!tell snarfed any way to get the response type (if any) of all the Bridgy (and other services's) webmentions? e.g. #/% comments, likes, reposts, rsvps, bookmarks, reacji, homepage mentions, other. I know webmention.io has that data. webmention.heroku should too (both offer response type specific APIs/embeds)
tantek!tell aaronpk any way to tell what #s / %s of the webmention.io and Telegraph webmentions are what type of /response ? comment, like, repost, rsvp, bookmark, reacji, homepage mention, others?
tantek!tell snarfed would be worth updating https://snarfed.org/1-million-webmentions with the % response types, that will help really hit home the user-visible impact that webmentions have had
tantek!tell snarfed and third, re: "Long tail: Unknown; estimate 5-50k", presumably indiemap has crawled enough of our indieweb blogs / posts to be able to discover when/how many indieweb *posts* have how many in their comments sections to indieweb *responses* permalinks - each of those you should be able to count as at least one successfully sent webmention (not counting updates0
ZegnatI am removing the “Regrets” header. I would rather we focus on getting people to RSVP at all. I also can’t find a single 2017 HWC that had someone put there name on Regrets.
ZegnatThere used to be a separate category for the virtual HWCs, but it was decided to move them into their specific timeslot as all the events on the page are supposed to be sorted by start time. Thus vHWC Americas and vHWC EU have their separate headings.
ZegnatThe header structure has been flattened. “Regrets” wasn’t used in a year, so it is out. “When” was mostly inaccurate as we see HWCs picking different times to fit their audiences, so it is out. “What” has simply become the main description at the top of the page.
ZegnatThe hope is that this makes it slightly easier to start the page, as separate events are clear separately contained divs that can be cut and pasted, and that code for things like the newsletter and Kaja for automatic wiki updates can more reliably parse the event information.
ZegnatAnd this way, if people are using selfhosted indie events (like the London crew) they can use that as the u-url of the h-event on the wiki as well!
ZegnatI foresee having to watch the HTML like a hawk for the first few weeks. But once everyone has the event HTML of their city ready to copy and paste that issue should disappear.
ZegnatPeople were also getting timezones wrong copy pasting, and those have never been included in any of the microformats. Copying a wrong h-card is just as likely. I don’t see this adding extra fragility there.
tantekgetting two microformats marked up properly is harder than just getting one marked up properly - and harder = more fragile - is that not obvious?
ZegnatThe part where someone had to already go through wiki gardening to fix timezones that people weren’t copying right. If you have to go through anyway, this isn’t that hard to add.
ZegnatThe only thing this is adding as far as mf2 goes is correct start and end times (these were lacking before making the event mostly useless anyway) a single div element (where people previously were expected to copy the right amount of --- for a separator anyway) and a single p-name within the header.
ZegnatThe virtual EU one will probably move to accommodate people commuting after work. At that point I think not a single EU event is on the 17:30/18:30 time slot that was previously mentioned.
sknebelfor non-remote events timezones aren't that important, so no need to keep them IMHO, at least not without a consuming use case. (and since wiki-consuming code tends to be custom for now, guessing timezones is sort of possible, at least from what I've seen with IWC pages)
ZegnatNo, but accurate time (even without timezone) is. And as 1 event of the page, only reporting from the “When” section, it just didn’t express correct times at all.
sknebelit's to bad it seems like we're going to need the <time> elements, but getting the date somewhere page specific if at all possible is going to be hacky
ZegnatVery. We can’t get times through implied times because they differ. If we try to do implied date parts only, you have to be very careful with timezones, because PDT is actually organised on a different date when converted to UTC (unless I messed up my timeconversion)
sknebel(just to have it mentioned, for a one event-per-page design we also could get rid of the explicit time in mf2 and intro text completely. people reading are going to read, parsers are at least not reporting a wrong time)
ZegnatJudging from who actually ends up editing those pages I do not think it actually adds too much fragility on top of errors we were already seeing copy-pasting.
tantekactual "IndieWeb meetup" part of HWC in various cities seems to be predominantly 18:30 (Balitmore, London, Seattle, SF), one 18:00 (Nürnberg), and one 19:00 (Amsterdam)
tanteksknebel, re: newsletter is relevant for communicating HWCs, well, co-organizers need to add their cities to /Events#Upcoming HWC events, so far only SF is on Feb-Mar HWCs
sknebelnot sure how that is related to the question if people actually use the newsletter to get informed about events. My impression from talk between organizers was that it isn't, and I even got people asking if there maybe is a hidden version of the newsletter without all the event stuff
tantekalso, "without all the event stuff" = zero photos = boring wall of text - so people asking that are basically asking for something that they will ignore even more
tantekwhich makes sense, get people more interested, photos are emotionally appealing, make you want to read more, then the very next thing is how to meet some of those people - at the next events
sknebelthat makes sense for someone finding the newsletter online/getting it forward as "look at this"/..., less so for someone subscribing to the mails to get kept up-to-date
tanteksknebel: "to get kept up to date" - events with real people demonstrate actually healthy human community - rather than just yet another aggregation of random internet stuff that could be generated by robots