Organizers Meetups (and Organizers Summits) are half-day events held before IndieWeb Summits, and often quarterly before IndieWebCamps, for everyone who has co-organized an IndieWebCamp or organized 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!
Proposal: make "organizer" more present tense (active organizers) to emphasize/focus/encourage more active organizing (as well as empower new folks rather than just folks that have been around, with the goal of being more forward inclusive and less insidery). Specific changes:
- from co-organized an IWC (ever), to past 2 years
- from organized HWCs in past two years, to past 12 months
- +1 Tantek Çelik - I’m especially interested in thoughts/feedback from folks who would opt-out, would it be a relief, a feeling of being left out, or encouragement to be more active from now til the next Organizers meetup/summit?
- +1 gRegor Morrill
- I propose adding "or actively organizing an upcoming IWC" to the first condition. For example, while Eddie Hinkle might otherwise lapse in 2018-12, he is actively organizing 2019/Online.
- I'm someone who would be opted-out by these changes and I'm OK with that. It's a little bit of a relief, in the short term (I might feel more freed-up to work on personal things) and in longer term I think it would encourage me to organize again.
- +1 (with caveat) Eddie Hinkle - I think it helps to aid encouragement. With a strict view of those new changes I would be opted-out. However, I think if you embrace those rules an exception should be if they are actively planning another event (such as IWC). HWCs can be tricky because they could be "planning" an HWC for a long-time which should be discouraged since it shouldn't require as long as an IWC to plan. While the exception would keep me as an Organizer, more than it being about me, I think it embraces the spirit of the rule which is focusing on the present/future over the past.
- 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 Meetup 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)
session migrated to Organizers/event_pages
section migrated to Organizers/event_pages
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
- 2016 Organizers Summit
- 2017 Organizers Summit
- 2018 Organizers Summit
- NYC 2018 Organizers Meetup
- Berlin 2018 Organizers Meetup
- https://www.youtube.com/watch?v=WqnhN2Rzaqc 😂 (in case we forget)