aaronpkI'm separately rebuilding Loqi and will be able to make him join other channels easier as well as selectively enable various Loqi features per channel
tantekbesides, just going to point out that there's clearly an opportunity here to provide a general open web resource ("brought to you by the IndieWeb community") to replace the krijn IRC archives which used to be essential for #whatwg etc.
tantekand someone adding fuel to the subdomain fire as it were - since those are all reasons to potentially prefer a subdomain over just a subdirectory (opposite to my current vote)
Loqitantek meant to say: and somewhat adding fuel to the subdomain fire as it were - since those are all reasons to potentially prefer a subdomain over just a subdirectory (opposite to my current vote)
aaronpkThe only redeeming quality IRC has is that it's a relatively standard protocol so there are at least multiple clients you can use to connect to a server like freenode
tantek.comedited /rename_to_IndieWeb (+984) "/* docs subdomain */ agree with some/most of shaners, bnvk problem statements about content/design, but 100% disagreed with the illogical leap to subdomain/plumbing changes both because they don't help, will distract from solving actual problems" (view diff)
tantek.comedited /rename_to_IndieWeb (+642) "/* chat subdomain */ subdomains hurt branding, noting examples of big orgs that launched without or ditched subdomains deliberately, "uniform header bar" needs real world examples" (view diff)
tantek.comedited /rename_to_IndieWeb (+93) "/* chat subdirectory */ simplified/focused reasoning, plus noted subdomain considerations with brainstorming beyond IndieWeb community (i.e. if "chat" were to grow to become an open web resource in general, like how we archive socialwg logs)" (view diff)
tantekwe had an initial "vote" *only* for should we rename indiewebcamp.com to indieweb.org at all, which was a unanimous proposal put forward from IndieWeb Leaders Summit
ben_thatmustbemestill if many people +1 to something and you -1 a response to everyone it give it the appearance of a lot of conflict, whereas keeping the +/- 1/0 to the main level keeps things clear
tantek.comedited /rename_to_IndieWeb (+121) "/* Brainstorming */ clarify this section is gathering opinions, not voting, since these are all evolving brainstorms with multiple options, more/better options encouraged (per brainstorming)" (view diff)
bearI don't feel comfortable with "simple plan from the leaders summit" and "illogical leap to subdomain/plumbing changes" as it is telling me that my experience with plumbing is making the "simple plan" complicated just by expressing the opinion
bearit also implies (which I admit may be a misreading) that simply because the plan was simple and drawn up by the leadership summit, that it shouldn't be weighed down by feature creep
bearit's from the change message "# 02:08 tantek.com edited /rename_to_IndieWeb (+984) "/* docs subdomain */ agree with some/most of shaners, bnvk problem statements about content/design, but 100% disagreed with the illogical leap to subdomain/plumbing changes both because they don't help, will distract from solving actual problems" "
tantekbear, do you have a better suggestion for how to move forward when there are parts that have agreeemnt, and parts that do not? Especially when such parts are separable / capable of being done asynchronously or iteratively over time?
bear"illogical leap" and "simple plan" all carry overtones that imply we shouldn't bother with discussing things as they have been already been discussed and given
tantekpoint being, when there are parts that have rough consensus and can proceed forward, there's no need (in fact it is bad to) tie them to optional incremental parts which do not have rough consensus
bearthe one thing i'm taking away from this whole conversation across the last couple of days is that the set of items that need to be done and the discussion about them has been haphazard and not directed
ben_thatmustbemetantek: side note, any points of why microformats.org uses /wiki ? just because that was how it was done at the time and not really thought out?
tantekbear, yeah, have seen that happen more often than not in "group" projects, too easy for feature creep because it's easier to "want" something from a group effort than to make it happen
bearone change I would welcome is to remove implementation details, which includes subdomain or not, from the discussion and make sure we are focusing on what the issue is
Loqibear meant to say: one change I would welcome is to remove implementation details, which includes subdomain , from the discussion and make sure we are focusing on what the issue is
beara lot of what people are reacting to is that the framing of the discussion was not clear and multiple threads were attempted to be settled by the brainstorming section
tantekand frankly, those aspects (methodology of documenting issues first, and only second offering possible *solutions* (plural)) concern me much more than any particular problem or solution
tantek.comedited /rename_to_IndieWeb (+683) "expand my opninion, focused on agreements with others' problem statements, and offering of different reasoning as a summary/pointer instead of inline" (view diff)
tantekbear, even if the implementations have always been the same leads, that's not a justification with further burdening them with that responsibility / expectation
tantekwhen we discussed this at the leaders summit, the only *new* *potential* feature we discussed was 'events.' and we also recognized that wasn't built, and was not something we should do for July 4
bearand i'm trying (badly I know but i'm also very tired and have had to deal with things about my dad) to get across some of the vibe i've gotten from conversations i've seen
bearcool - sorry, I was taking a long and slow path to the point because I didn't want to come across as confrontational or get emotionally involved in the point
tantekhonestly some of the particular (e.g. chat. subdomain) I'd consider much more / be more potentially positive about, if they were clearly separated from the domain name change
tanteklike we're going to have to redirect indiewebcamp.com/irc/ URLs *anyway*, so having to also eventually redirect indieweb.org/irc/ URLs is not a big enough deal to justify a whole new project
bearmy only concern is that all of what your saying applies to the human indieweb - APIs may still have a place for some of the service plumbing but we should resist implementing them until we show that it can't be handled by mf2 markup
bearI would suggest some variation of "Use the existing mf2 markup your website already contains as your API. Remember that we should always be human first and application second."
tantek!tell ben_thatmustbeme re: "any points of why microformats.org uses /wiki ? just because that was how it was done at the time and not really thought out?" Because at the time it seemed to make sense to have a home page blog, a few static top level pages, and then the wiki only for research, proposals, brainstorms, specs, etc. And over time we (founders + active community) discovered that was a mistake, static pages were neglected
tantek!tell ben_thatmustbeme wiki was latest / out-improved both the blog and the prettier "few static top level pages" . Turned out ease of editing > "pretty / friendly pages" which were more about people having time to do text+graphics than URL/backend choices.
tantek!tell bnvk re: onboarding, we have /Getting_Started but that's about getting started with your own site. Do you mean onboarding into the community? Hopefully that's minimal work, but the important parts are in /wikifying - feel free to ask Qs to help with that.
aaronpki also agree with ben_thatmustbeme that regardless of whether you call this "polling" or "voting", it *looks* like voting and so everything looks more adversarial than it should
aaronpkthe reason the chat logs are tied to the july 4 switch is because we're launching multiple channels on july 4 and there isn't a way for me to publish multiple channels with the existing system http://indiewebcamp.com/irc/2016-06-25/line/1466849407031
Loqi[tantek] like we're going to have to redirect indiewebcamp.com/irc/ URLs *anyway*, so having to also eventually redirect indieweb.org/irc/ URLs is not a big enough deal to justify a whole new project...
aaronpkand "whole new project" is an exaggeration, since what's really going to happen is i'm going to end up modifying the existing logs until it works with multiple channels
aaronpkreviewing http://indiewebcamp.com/rename_to_IndieWeb ... the only thing there that 1) wasn't previously discussed AND 2) is not something we have to decide before the july 4 move is the docs subdomain.
tantekBTW this kind of polling (with updates and current state *and* contextual documentation) is something that a wiki page does better than a GH issue
tantekaaronpk - crazy suggestion: what if we scaled back the multiple channels switch for July 4? and only switch #indiewebcamp -> #indieweb on that day?
aaronparecki.comedited /rename_to_IndieWeb (+2) ""flip the switch" does not accurately reflect the work required to make the change, and makes it sound easier than it actually is" (view diff)
tanteknow I see how a "must fix this to ship" issue became a "hey this is a better overall solution" change/update to the plan which allowed consideration of "new" features as well
tantekinteresting "product" launch trade-offs thinking/discussion, when an issue suggests more development, sometimes scaling back the scope can be better
aaronparecki.comedited /indieweb.org (+4612) "move docs subdomain section to this page since it is a new proposal and not required as part of renaming indiewebcamp.com to indieweb.org" (view diff)
aaronpkthe "brainstorming" header on /rename_to_IndieWeb is not intended to be future brainstorming, it is intended to be implementation details of the rename
aaronpknews.indiewebcamp.com is not technically essential since it can stay there while everything else moves, but from a branding perspective it is connected to the move
aaronpkthe name "offtopic" was brought up after summit, but iirc we didn't come to a conclusion on what the name of that channel would be during summit
tantekdespite the silo-pref, I suggest "indieweb-random", following Slack naming conventions, may be *more* friendly to non-devs / and further Generations 2+ etc. since they are more likely to have used Slack than IRC. instead of indieweb-offtopic
Loqibnvk: tantek left you a message 2 hours, 53 minutes ago: re: onboarding, we have /Getting_Started but that's about getting started with your own site. Do you mean onboarding into the community? Hopefully that's minimal work, but the important parts are in /wikifying - feel free to ask Qs to help with that. http://indiewebcamp.com/irc/2016-06-25/line/1466866100263
tantek.comedited /rename_to_IndieWeb (+1211) "/* new name for off topic channel */ offering another alternative, "indieweb-random" based on Slack default, and small data sampling, 50% of teams seem to have random, more than any other option, and zero have "offtopic"" (view diff)
tantekhmm - that reminds me, I need to suggest somewhere some way to build our own backend flat search for the logs. Google's indexing has gotten really incomplete
tantekaaronpk yes yes ;) I'm *trying* to be more "next generations" empathetic here with the "random" proposal. I know "off topic" is a comfort zone for me :P
bearrandom always annoys me when I find it on a slack community - but I get why it's helpful if other channels are supposed to be rigid about the topic
voxpelliRegarding Slack's #random, it's a bit different in Slack because it has an additional level that IRC doesn't – you have the Slack itself and then different topic channels within Slack, so everything can be on topic somewhere
aaronpkit's also important to note that design decisions made by Slack should not necessarily be given a lot of weight because Slack was designed for communication within a company, and explicitly not for public/community chat
bearmy suggestion for default chat rooms would be to pick the smallest set that solves the immediate need- indieweb-chat indieweb-dev indieweb-offtopic (because they are what terms we use now) and then see what the rate of conversations are in each and put in the topic a feedback link
[chrisaldrich]I'm putting together a potential IndieWeb intro session for WordCamp Los Angeles as an overview (particularly in anticipation of IndieWebCamp in LA in November). Does anyone have a suggestion for a catchy (maybe even linkbaity) title?
[chrisaldrich]thanks bear, yeah, I've seen that and a bevy of youtube videos... Ideally I'd like to recruit gen1 users, but want to be welcoming of gen2 and 3 who will certainly be there in spades.
beardo you know what the solution set for gen1 is and what it would be for gen2+ ? knowing what topics are unique to them and then riffing off of those items would be a good starting point
[chrisaldrich]They're doing 35min of presentation with 10 min for Q&A, so it'll have to be a relatively quick intro; the goal is to infect as large an audience with the overall concept with the anticipation that those interested will join us a week/month later for the IndieWebCamp in LA/Santa Monica
[chrisaldrich]I'm a biomedical engineer with a background in microbiology, so I always think infect first, but inspire is probably the better word -- thanks aaronpk!
[chrisaldrich]bear: I think your intuition on having one place to post (plus the added value of owning all your own data) is certainly one of the most valuable pieces for gen2
[chrisaldrich]I've lately been thinking about the marketing community, for whom owning data is/could be a much larger value. Many apps and platforms are geared toward syndicating content, why shouldn't it be built into one's platform de novo?
[chrisaldrich]Though on first blush reading the first, I find it interesting to think that Twitter's API program was "self-innoculated" which seemed to have heavily slowed their growth...
aaronpkspeaking of jumping ahead to implementation, i'm realizing a lot of the work i've done so far in rebuilding Loqi has been without a clear design in mind, so... back to the drawing board as it were
ben_thatmustbemeaaronpk: re: the indiewebcampofftopic, it was the idea of a logged off-topic chat, it was all happening at an IWC, seemed to be missed by tantek at the time
Loqiben_thatmustbeme: tantek left you a message 7 hours, 56 minutes ago: re: "any points of why microformats.org uses /wiki ? just because that was how it was done at the time and not really thought out?" Because at the time it seemed to make sense to have a home page blog, a few static top level pages, and then the wiki only for research, proposals, brainstorms, specs, etc. And over time we (founders + active community) discovered that was a mistake, static pages were neglected http://indiewebcamp.com/irc/2016-06-25/line/1466864933808
Loqiben_thatmustbeme: tantek left you a message 7 hours, 55 minutes ago: wiki was latest / out-improved both the blog and the prettier "few static top level pages" . Turned out ease of editing > "pretty / friendly pages" which were more about people having time to do text+graphics than URL/backend choices. http://indiewebcamp.com/irc/2016-06-25/line/1466865009116
sknebelwhat is the important difference between "chat-interface" and "traditional" readers for you? more compact presentation? different notion of read/unread (read as soon as you've seen the headline, not on interaction?)
sknebelthat sounds like something a traditional reader-like system could implement as well, it's just easier to DIY/script in chat tools you are used to hacking on?
sknebelfor me a big issue is selecting what I want to pay attention to. right now I basically go through the headlines, "star" what I'd like to read, then mark everything as read, which is kinda kludgy. (using inoreader, which is fairly google-reader-ish in its UI)
bearsknebel - part of that is why I am trying to use as much of mf2 as I can - because star'ing and replys and the like will all come along for the ride
sknebelis the key point for you and aaronpk is that you want it to be more like a stream, less like an e-mail UI (which IMHO forces you to have some kind of interaction with everything)? Does that make sense?
aaronpkbear: the reason i think they're different is that if you look at the posts on my site with categories (tags), it's very likely i will want some of those to be pushed to different "chat rooms" based on things other than the values of the categories
aaronpki actually recently added "#indiewebcamp on freenode" as a syndication destination in my site, so I can click that in Quill and it'll post in IRC as me
aaronpkThis post looks out of context on my site, but it's syndicated to #indiewebcamp on Freenode because I clicked that button in my posting interface.
Loqi[Aaron Parecki] This post looks out of context on my site, but it's syndicated to #indiewebcamp on Freenode because I clicked that button in my posting interface....
bearmy thinking on posts losing context would be to handle it like loqi does now - try and see what mf2 helper data is available and construct an IRC message that makes sense -- url's, see-also's and other items
KevinMarks_sknebel - whta yOU call a strema i call a flow it doesn't present an unread count of messages, just a list of recent ones, so you don't have email's inbox problem - the implicit pressure to turn bold things plain and get that unread number down. Instead, you can dip in and out of it, when you have time, and what you see is notes from people you care about."
aaronpkusing pubsub for it would imply that the "chat server" would be subscribing to a feed of yours. whereas webmention implies that you push to the server each message
sknebel(I'm somehow imagining a bunch of xLoqis in a chatroom somewhere "quick, somebody in #indiewebcamp asked what X is!" "X is ...", everybody with a different sub-skillset)