Organizers Meetups (and Organizers Summits) are half-day events for everyone who has co-organized an IndieWebCamp or was active organizing Homebrew Website Club meetups in the past two years. Due to the spread-out nature of our community, many attend remotely.
These meetups were formerly called Leaders Meetups. At the 2018 NYC Organizers Meetup organizers decided to rename them to avoid the sound of elitism or intentional hierarchy; and because we want to encourage anyone to become an organizer!
- 1 next
- 2 Issues
- 3 planning considerations
- 4 Events Issues
- 5 Events Brainstorming
- 6 Brainstorming
- 7 past
- 8 See Also
If you're planning an IndieWebCamp between now and the next summit, and want to organize an Organizers Summit beforehand, drop a heads-up here linking to your IndieWebCamp's planning page with details about a proposed Organizers Meetup.
Collect issues here until a specific agenda page for the event is created
Martijn van der Ven: I think we discussed doing it quarterly, or at least three times a year aligning with major IWCs, at the last Organizers Summit. This still makes a lot of sense to me. Though maybe it has been failing because planning an actual get together the day/night before an event is hard, and we should decouple it from the “major IWC” mark?
which channel for WordPress development
- There has been a little discussion about this again lately. As the appeal of the WordPress plugins is growing, more non-gen1 people turn up to #-wordpress looking for help setting things up. To not alienate these people, development talk has shifted back into #-dev.
- User support is nice in #-wordpress, as the main channel is mostly active with gen1-type people on their own custom workflows who can be of little help to WordPress setups. The people who do run WordPress are probably in #-wordpress and happy to help there.
- WordPress plugin development, especially if multiple devs are online, can quickly fill up all of #-dev. This was one of the original reasons there was a fork into #-wordpress: 2017/Organizers#Discussion_Channels so we should stick with that. If there's a need for separate WP channels for WP users vs WP devs, we can consider that.
IndieWeb Community Infrastructure
- What services are essential for running the IndieWeb community resources, and who has access to them?
- Domain name(s)
- Who has access to
indieweb.org, can configure the DNS, etc?
- How can access to these be split amongst several people?
- Who has access to
- Who can manage the Slack server / channels?
- Who can manage the IRC channels?
- It looks like we have several
+opeople. Are they all listed as Founders or equal on ChanServ?
- all ops are in US timezones and thus not available on EU mornings (discussed 2017-12-17 due to small spam-wave on Freenode)
- Is there anything to gain from registering with Freenode? (or has this been done already?)
- It looks like we have several
- Is there any managing we have to do for the Matrix bridge?
- How quickly could a new Slack bridge be created if Loqi goes down? The bridge code is available on GitHub.
- Official channels
- For projects we depend on, e.g. the Slack bridge, should they be mirrored to the indieweb GitHub account? That way the community has them even if the original author decides the remove their repository.
- Third parties we depend on? Can more of these be self-hosted?
- Currently the wiki login only works through IndieAuth.com.
For IWC organising, is it interesting to state kid friendliness somewhere?
- Sparked by 2017-12-16 : Kid friendly PHP
- how well is it working?
- how can it be improved? donations, applications, reviews, approvals, etc.
- Should this be available for any IndieWebCamp? or just Summit?
- How can we formalize this as an ongoing thing, either as a standing fund for any IWC or as an annual Summit thing?
- We need to document and publicize the process for applying, reviewing, and approving requests
- We should try to get matching donations when we can
Evaluate barrier of entry to wiki / wiki use-case
Added by: Martijn van der Ven
This came up in relation to diversity, mostly regarding how accessible the community is to new entrants. Please read the discussion in the #indieweb-meta chat channel from 2018-09-01, 15:12 UTC, to about 17:08. Some choice bullet points and quotes:
- Aaron Parecki asked Jon if they could add their feedback on diversity to the wiki. This is a relatively common thing within the community to do: putting stuff on the wiki is an established workflow, and so is asking others to contribute to the wiki.
- Jon pointed out that this adds some definite barrier of entry for people. They had to go through multiple steps – taking a good 20 minutes – to add something to the wiki. Something they had already thought to have communicated through chat.
The barrier restricts participation to the current non-diverse group of insiders. The default response of “put it on the wiki” immediately confronts outsiders people with this barrier. I’ve talked with more than one person who checked out the Indieweb chat room and had the reaction that it was a really hostile place because of this and so decided not to get involved.
the situation was somebody (me) who’s not in the core Indieweb community had some suggestions about how to make it more diverse. The response was to ask me to put it on the wiki. Requiring IndieAuth is a barrier to the group getting suggestions from a outside the core. No matter what the purpose of the wiki is, that’s going to be a problem for diversity
- Martijn van der Ven feels that the solution depends on whether the wiki is meant for this type of feedback or not. And that the barrier to entry should be adjusted depending on that.
my point is that the solution to the situation depends on us deciding what the wiki is for. Either we lower the barrier for wiki edits, or we stop asking people who aren't assimilated in to the community to put their feedback on the wiki.
- Aaron Parecki clarifies that the existing barriers (mainly the IndieAuth/RelMeAuth requirement) are there by design.
- Martijn van der Ven is especially interested in hearing from Organizers who have helped onboarding new users on the wiki. Tantek Çelik and Greg McVerry come to mind.
- The wiki used to be the way to register for IWC, so this barrier made sense to help restrict to creators or their apprentices. At 2016, we started selling tickets so this wasn't a barrier for IWC. Currently, I think this barrier primarily serves to keep spam off the wiki. I'm open to the idea of opening registration to the wiki somehow. I know that's probably not trivial and makes more work for organizers (some coding to make regular + IndieAuth sign-in work, moderating spam accounts), but maybe it's worth it? gRegor Morrill 22:19, 2 September 2018 (PDT)
Evaluate if/how to apply Code of Conduct for outside events
What do we do if someone shows up at an IndieWeb event who has done things outside of IndieWeb events that would be considered a violation of the CoC? There was some discussion at lunch after 2018/Organizers and then occasionally in #meta [chat log links needed] about this.
- 2018-09-02: What would we do if it was reported that someone had been harassing others via their own site or a federated service like Mastodon?
Tantek Çelik: Let's improve how we promote our events, towards goals of:
- increasing participation overall
- especially increasing diversity of participation
- especially increasing breadth of generations represented
- Set dates farther in advance
- e.g. for IWS 2020, set dates *before* IWS 2019, and at least a venue/date confirmed *before* next year's XOXO for the *next* IWS (2020)
- Design, print, distribute "save the date" postcards
- e.g. during IWS and XOXO where people are motivated to plan a trip back to Portland ASAP
- or without a date/venue, and get people to put their address on them and offer to mail them out when we know the date & venue!
- The sooner we can send "save the date" announcements/card, the sooner that folks interested can blockout the dates on their calendar so that when it *does* come to decision time months later, they find they have the time to go (and have not accidentally scheduled something else that weekend)
- Make postcards to hand out in person
- 1. designer for "save the date" post cards
- 2. printing a whole bunch of them in full color
- we could also create a *physical mail* sign-up list for people to receive post-cards when we know the date and print cards later.
- 3. pre-stamp cards for mailing said post cards to said people signed-up
- Participate in diverse events (like XOXO) and hand out "save the date" post cards etc.
- "Save the date" stamp to stamp the backs of stickers, along with the classic "library date" stamp for start-end dates!
- allows cheap just-in-time re-use of existing generic IWC sticker stock, and customizing for any event in the future as soon as its dates are known!
- Location requires good internet for streaming
- Some kind of conference room microphone or professional videoconference setup (Mozilla locations have Vidyo, which has worked well)
- see also: remote participation
- time: due to the international nature of the community, good times are mornings on the US west coast and evenings in Europe (e.g. 2017/Organizers was at 09:00 PDT (UTC-7) == 16:00 UTC == 18:00 CEST (UTC+2)
Mediawiki awkward for events
One of our more awkward uses of MediaWiki is using it as an events calendar.
Multiple places to update
- Adding an event like an IndieWebCamp or Homebrew Website Club involves updating several locations
Creating new HWC pages is tedious
- Copy+pasting to create new HWC pages is tedious, and is typically only done by Gregor and Tantek
- Entering all the HTML required to format the page as an h-event is error prone
Wiki pages require manual RSVP
- Not easily able to add new features like accepting RSVPs to the wiki pages themselves
Event pages need better presentation
- The event pages look like wiki pages, with little visual hierarchy, and are not immediately recognizable as an event you can RSVP to to the general public
Events Problem Statements
- Lots of manual work to create / update events on indieweb.org (most often for Homebrew Website Club, updating Events, Main_Page, and Sidebar.
- Group event sites are hard, especially ones that take into account any particular community's needs
- Just changing the plumbing. Just changing the plumbing has pretty much no positive (likely more negative) effect on usability. E.g. (just "let's use jekyll for that")
- Just replace the editing UI / wiki mark-up/down syntax. E.g. the "simple web interface" benefit of jekyll is actually more complicated than the current wiki which is also a web interface. I.e. if all you're doing is replacing wiki markup with markdown, it's not a benefit. mediawiki: wiki syntax + mediawiki templates. jekyll: markdown + yaml blocks and includes. they're not actually that different.
- "learning one more system" = worse overall UX.
- Aspirational new system proposed by non-users of current system. The "I won't use the existing system because I hate wikis" argument is not a good argument, as absence of use of a current system provides no evidence that any new system would gain any use at all.
Events Replacement Requirements
Capturing here from IRC, some thoughts on possible requirements for any proposals to improve / replace entirety of how we create / update events on the IndieWeb.org site itself.
- Maintenance commitment up front. Volunteers to build a new system should also consider volunteering to maintain it, otherwise it's just trading one (known) maintenance tax (updating multiple places in the wiki, annoying, but simple/easy that anyone can do it), for another (unknown) maintenance tax (updating/fixing software, likely much harder, means it doesn't get done).
- Try and learn current system first. Volunteers to design/build/replace events should at least *try* actively updating / creating events on indieweb.org so that they have some direct first-person understanding of the needs of the community. Without that first-hand knowledge, any such proposal is likely ignorant of the community's actual needs.
- Start with UI/UX sketches. Anything any of us want to build to replace the wiki events should start out with UI/UX sketches, no code at all.
- Support your own indie events first. Group events software is so much harder / more complex than indie event / RSVP posting support (likely a superset of), that that would make a good prerequisite for any proposals/proposers.
Separate Events Site
We have also set up 2016.indieweb.org/nyc2 for IndieWebCamp NYC2.
Possibilities for expanding use of a separate site for events.
- Continue with YYYY.indieweb.org
- New subdomain events.indieweb.org
Some events options to consider
- keep using YYYY.indieweb.org for annual summits, and YYYY.indieweb.org/CITYABBR for specific IndieWebCamps
- build our own minimal event interface
- adopt an existing running project such as Calagator
- wait for an in-progress project such as Dark Matter Eventer
- Some level of unstructured content on event pages, so that we can allow our use of it to continue to evolve over time.
- Be able to quickly duplicate an event rather than set up recurring events (like Calagator's "clone" function)
- Events must support multiple locations and varying start times and timezones per location (our HWC events do this currently)
- Quickly add links to posts (notes, photos, articles) about an event
- Highlight photos from events
- Upload photos directly to the wiki or event page
- By retrieving linked photos in indieweb photo posts / tweets / instagram posts
- RSVP via Webmention like http://2016.indieweb.org
- RSVP directly on the page (an "I'm Going" button after you're logged in)
Tickets and Registration
For the past couple years, we've had a separate ticketing website for letting people register/buy tickets to the events. We've found that having an explicit step of acquiring the ticket leads to better no-show rates. In 2016, the attendance rate of people who RSVPd from their website was 73%, vs that of people who bought a $5 ticket was 39%.
There isn't any value gained by having the registration system outside of the main event page, so integrating them would certainly be a good goal. Here are the features of the registration system that have been useful.
- Accepting payments for tickets.
- Issuing "tickets" in a way that feels stronger than just RSVPing for the event.
- Collecting the person's email address
- Providing a way to contact them before the event, such as sending reminders leading up to the event.
Other community events examples
- WordCamps, which have many properties in common with Indiewebcamps
- Uses wordcamp.org (likely derived from barcamp.org), a TLD different from the community: wordpress.org
- Philosophy: a main landing page and using subdomains for the individual events, with year/location.
- Making wordcamp.org itself the page for upcoming events
- Use subdomains on wordcamp.org for specific events
- Issues: they had an issue with URL structure last year.
- Uses wordcamp.org (likely derived from barcamp.org), a TLD different from the community: wordpress.org
Below is my brainstorm for a How To section for this page after our discussion at 2018/NYC/Organizers.
Each new meetup page would also include a link to this How To section and a note that attending organizers can add urgent issues directly on that page. gRegor Morrill 14:20, 27 September 2018 (PDT)
Add an Issue
Everyone is encouraged to add new issues to Organizers#Issues. If you prefer to raise an issue privately, you can contact a community organizer. When adding an issue to the wiki, please include the current date.
If you are an organizer who is attending the next meetup and there is an urgent issue, you can add it directly to the agenda on that meetup's page.
Process Issues at the Organizers Meetup
- Create an etherpad for the meetup
- Review the task list from the previous meetup
- Review the issues on the meetup's agenda, open issues from the previous meetup, and Organizers#Issues to prioritize the sessions
- Add sessions to the etherpad as they are discussed
- Copy the issue's wiki text into the etherpad, then take notes underneath. This makes archiving easier.
Archive after the Organizers Meetup
- Archive the etherpad sessions in the Sessions section of the meetup's page, including the original issue's wiki text
- Remove the original issue from Organizers#Issues. Include a link to the meetup session in the edit summary.
- Add any todos to the Task List section
- Add any issues that require further discussion to the Open Issues section
- https://www.youtube.com/watch?v=WqnhN2Rzaqc 😂 (in case we forget)