Finalising topics for the Community Summit

The Community Summit is going to be hosted in Paris just a few days before WordCamp Europe, on 13 & 14 June 2017. We are at the stage now where all contribution teams are being asked to finalise their topics for the Summit, so that is what I would like to do here. The deadline for final topics is 9 June 2017.

The currently proposed topics for all teams are listed here, and these are the ones for the Community Team:

  1. Global involvement in the Community Team
    • Language barriers
    • Diversity
  2. WordCamps & Money
    • Responsible use of WordCamp funds within the new legal structure
    • Sponsoring volunteers
    • Sponsorship levels
    • Better value for sponsors
    • Cost of swag
  3. Marketing & Engagement
    • Engaging people outside the WordPress bubble
    • More involvement at meetups & WordCamps
    • Going from a strong meetup to a WordCamp
  4. Paying for speaker travel
  5. Regional camps
  6. Improving deputy training
    • Improving training materials
    • Keeping deputies updated
  7. Code of Conduct and harassment reports
    • Training organisers on how to handle harassment reports
    • Reviewing the Code of Conduct to be more inclusive
  8. Supporting other event types
    • Financial and logistical support for different types of events
    • Microgrants tool

What we need to know from the community and our deputies (whether you will be attending the Summit or not), is the following:

1. Which of those topics do you think we could sort out in a Slack and/or P2 discussion before the Summit?
2. Are there any additional topics that you feel are important for us to discuss at the Summit?

While answering those questions, please bear the following from the Summit announcement post in mind:

The main purpose of the summit is to move the project forward before and after the event, with the event being a milestone in a larger set of work.

With this main goal in mind, we’ll touch base with all team reps to figure out which of the topics proposed can be handled beforehand, and come up with topics that would be:

1) of importance to the project as a whole
2) would benefit from cross-team collaboration
3) will leave us in a better position than when we started

#community-summit #wceu

Community Summit Working Day Plan

For those at the community summit, here’s the general plan for our team on Thursday.

8-9am: Arrive

9am: Opening Remarks

9:15am: Outline the projects we are going to work on, and divide up who’s doing what. Some projects will be able to start right in on doing actual tasks, while others will be planning meetings. Some projects will be better suited for deputies, some for organizers, and some it really won’t matter. There will be a variety of two types of projects you can choose to work on.

  • Tasks that once we’ve gone through what to do, you are off and running, a production machine helping us accomplish stuff through what some might consider drudgery, but in reality is the [insert useful metaphor here; it’s very late. 🙂 ]
  • Conversations/planning that have to happen to plot out a project or create outlines that can be used to frame the work we do after the summit is over and into the coming year.

[work on our project assignments]

11:30am: Projects teams report on what they’ve each gotten done (lightning style) and we all confirm or change afternoon project plans

12 – 1:30pm: Lunch

1:30pm: Dive back in as determined before lunch. For people switching to new projects, do any setup/training needed to get them started.

[work on project assignments]

3:30pm: Projects recaps again, and then general community team chat to talk about team goals and metrics for 2016

4:40 – 5pm: Closing Summit Q&A

#community-management, #community-summit

Community Team at the Community Summit

There will be about 50 people who declared themselves members of the community team at the summit happening over the next two days in Philadelphia. This includes deputies as well as local WC/meetup organizers. I think there are also some people listed as community team who are not tied to our team at all and meant they were part of the WP community and just wanted to attend, but in any case it’s a lot of people. I wanted to post some things to think about for unconference discussions tomorrow and our team working day Wednesday.

The summit format of safe-space conversations — no presentations — is intended to make it easier for us to talk about hard subjects that are difficult to communicate about using our normal online tools. This might mean things that are unpleasant, or things that inspire passionate contradicting opinions, or things that are sensitive and need a little more privacy to discuss fully. Let’s try to focus on that kind of stuff as much as possible tomorrow, vs general program planning ideas, which we can hit the next day on our own without cross-project collaboration.

Aside from the ones proposed in the summit forum, here are some topics that might be worth discussing tomorrow:

  • Inclusive/welcoming venue rules for WP events. This most often comes up when someone wants to use a religious venue owned by a church that has doctrine that is not welcoming to LGBT folks, though that’s not the only example. This issue was at play in what happened with Austin this year, so let’s talk about it and figure out what makes sense as a rule to ensure that everyone will feel welcome at official events.
  • WC/Meetup organizer location. Do they really need to be local to the community in question? We’ve always said yes, for the sake of being present in the community, having a stake in the game, being a local leader and resource. Some people think this shouldn’t be a requirement at all. Where should this line fall?
  • Meetup/WC relationship. Should meetup organizers need to have moved to the community program vs. privately owning meetup groups to be approved as a WC organizer or does it really matter?
  • Deputy duties/automation. What tasks should volunteers be doing, what tasks should people getting paid be doing, what tasks should a computer be doing instead of all this one-on-one communication? In short, how can we make the program more efficient and effective while making it more inclusive?
  • Escalation, code of conduct, poisonous people. This is really a working session, since we have some people identified to work on it already as an escalation team (and can add more volunteers to a working session) but some people may want to talk about goals and such vs. getting down to business.
  • The future of community summits. The first one was standalone. The second surveyed past attendees and decided to experiment with tying itself to a WC. This year is similar to last year, but we skipped over the taking stock of past attendees to see if people thought it was better with a WC or as a standalone event. Let’s discuss what future experiments with community summits might look like.
  • WordCamp.org URLs. It took years of complaints about the year.city format to be changed to city./year. Now we’ve been asked to revert that change (you may have noticed WCUS uses the old format). There wasn’t much discussion on posts about this, but I know there are a lot of people with opinions about which format is preferable and why.
  • Diversity and inclusion. We talk about being a welcoming community, and we are more welcoming than many open source projects, but it’s also true that a majority of project leadership is white male programmers. What can we do to diversify the contributor pool, to be more inclusive with the people who are here, and generally be less homogenous?

Some potential working projects for Wednesday (we can also see what we come up with in Tuesday discussions before deciding anything about Wednesday):

  • Escalation/CoC update/reporting form. Needs @mor10.
  • Organizer self-training/quizzes. We have been talking about turning orientations and trainings into self-guided online learning for years. Let’s just start.
  • Payments plugin. Plan the UX of payments/invoicing plugin improvements.
  • Sponsorship terms. Building off the levels reently posted, nail down the benefits that will go with each, since we won’t have IRS rules anymore to restrict us.
  • Course planning. Plot out courses we could run as diversity inititatives. Consult with training team.
  • Speaker gender review. I have done this by hand by myself manually in past years, to track how we are doing with regard to percentages of WC speakers who are women. I have started on this year’s review, but a couple of volunteers (especially from Europe and Asia where you might already familiar with speakers) to help fill in the spreadsheet would be great.
  • Redux of all predefs in supportpress. Survey of them started a while back by Josepha, need email rewrites and clearing out the ones that are not needed/not good.
  • Redux of auto-emails to WC org teams. Adding extra organizer roles will allow us to send more specific auto-emails to people volunteering in specific roles on org teams to make sure the right people are getting the information they need. Review existing emails, break them up as needed, and/or write new ones based on our organizer rules, checklists, etc.
  • Community Hub take II.We tend to use this as a catchall term — is it a meetup.com replacement? A way to track org teams and communicate with them? More? Less? Other? Let’s reconvene on this topic and narrow down what is really needed, based on the infrastructure we have to work with.
  • Make homepage redux. Revisit ideas of a couple years back around content for Make landing page to feature interviews, contributor drives, etc.
  • Email editorial calendar. Make a calendar of planned communications to meetup and other organizers for the coming year and identify who’s responsible for writing them (thinking a handful of deputies could be involved and rotate rather than one lone figurehead representing the program).
  • Contributor outreach planning. Get Involved tables at WCs, regular contributor drives publicize through meetups, other ways to get more activities in place to help people become contributors.

Some of these may resonate strongly with you, some may sound like a waste of time, and many will fall somewhere in between. There will be more conversations going on at once than anyone can be a part of — try to be okay with not being in every discussion, and know that no final decisions about the community program will be made by discussion groups on Tuesday without being reviewed here first to allow input from team members who weren’t able to travel here for the event.

#community-management, #community-summit, #wcus

Potential 2015 Community Summit dates

If you’re interested in a 2015 Community Summit please go fill out this quick two question survey: https://2015.us.wordcamp.org/2015/08/11/2015-wordpress-community-summit-dates/

#community-management, #community-summit

Improving WordCamp.org: Adding More Themes and/or Page Templates

This post continues the previous discussions we’ve had on the project to improve WordCamp.org. If you’d like some background information, you can check out the notes from the 2014 Community Summit and the discussion on the CSS Editor.

* * * *

 

One of the most common pieces of feedback has been that, when organizers are building their sites, they want more themes and/or page templates to choose from. The goal of this post is to start a conversation on that topic and hash out the details of what we want and how to move forward.

Right now organizers can only choose from the Core themes (TwentyTwelve, TwentyFourteen, etc) plus the WordCamp Base theme, a custom theme that was written specifically for WordCamps. Organizers can’t edit the PHP, HTML and JavaScript of the themes due to security and maintenance concerns, so customizing the CSS is the only way to create a new design. There’s a lot that can be done with just CSS, but sometimes organizers still wish they had more options.

Define the Problem and Goals

I think it’d help to have some specific examples of limitations, and to describe what the goals are in having more choices. These questions should help start the discussion, but feel free to ask/answer others too.

  • Have you run into limitations customizing your site? If so, can you describe them?
  • Do you find that it takes too much work to transform the design of the available themes into your custom design?
  • Do you run into situations where you can’t achieve the design you want without modifying the theme’s HTML?
  • Are there other major problems that you run into?
  • What do you think would be good solutions to the problems you found?

Potential Solutions

So far two potential solutions have been discussed: making more themes available to choose from, and providing a way for organizers to submit custom page templates for any available theme.

They’re not mutually exclusive, so we could possibly do both, but we have limited resources, so I think it’d be best to pick the one that will make the most impact and focus on that first. After the first round of improvements are made, we can reassess where we are and what to do next.

Other than those two, are there any other solutions that should be considered?

Adding More Themes

The first potential solution would be to simply make more themes available to organizers. This would save time in some cases because you could start with something that is closer to your custom design.

It would also provide a wider variety of layouts and templates, which could solve some of the problems related to needing a specific layout in order to achieve a particular custom design. If a developer did run into that problem, though, they would still be stuck because they wouldn’t be able to edit the HTML.

Just like with plugins, we have to be careful about security, performance, etc when adding more themes, but those concerns could mostly be mitigated by picking themes that are available in both the WordPress.org directory, and on WordPress.com. Those themes have passed an exhaustive review by trusted developers, so we would be able to assume that they’re safe without having to audit them ourselves.

Do you think this is a good solution? If so, which specific themes would you choose?

Are there any problems with it?

Accepting Custom Page Templates

Another potential solution would be to allow organizers to write custom page templates, so that they could create custom layouts for the content area if their design required it. The templates wouldn’t affect the header, sidebar or footer, though. In order to use the templates, we’d need to create child themes for the existing themes, and add them there.

The templates would have to meet certain criteria, and be reviewed for security and other concerns before they could be added to WordCamp.org. We wouldn’t want to end up with dozens of templates that are only relevant to a single camp, or to have to review new templates for every site, so I think we’d have to require that the templates be generic enough to be reused by other camps, and that they only be created when there is a significant need that can’t be accomplished with CSS alone.

What do you think about this solution? Are there any specific page templates that you think would be useful?

Are there any problems with it?

 

Do you have any other thoughts or comments?

 

Everyone is encouraged to particpate in the discussion, but I’m pinging the people who took part in the previous discussions to make sure they don’t miss the post: @ryelle, @harbormark, @chanthaboune, @nvwd, @kovshenin, @rafaehlers, @davidjlaietta, @dimensionmedia, @mj12982, @iandstewart, @miss_jwo, @topher1kenobe, @jenmylo, @georgestephanis

#community-summit, #improving-wordcamp-org, #official-websites, #page-templates, #themes, #wordcamp-org

Improving WordCamp.org: User Experience of the CSS Editor

One of the discussions we had at the 2014 Community Summit was about customizing WordCamp.org sites, and we identified some of the worst pain-points that organizers currently have.

One of those problems was that customizing a theme’s CSS is difficult and frustrating. Currently, organizers use Jetpack’s CSS Editor, which works well for small tweaks, but isn’t really intended for the types of major overhauls that most WordCamps are doing. Some of the biggest problems are:

  • There isn’t any post-locking or version control, so it’s easy for two users to accidentally overwrite each other’s changes
  • Saving edits requires a page refresh, which makes you lose your place. With larger rulesets, finding your place again takes too long and often breaks mental “flow”, which is frustrating.
  • The browser’s built-in Find functionality doesn’t always work
  • The rules can’t be modularized into small, manageable files — and then recombined during processing — for easier development and maintenance.
  • Many consider editing in a browser to be a subpar experience to using an IDE with features like code-completion
  • Cross-browser/device testing can’t be easily done with the Preview functionality
  • Syncing between production and a local testing environment has to be done manually
  • Time-saving tools like LiveReload can’t be used.
  • There are two scroll bars (one for the page itself, and then another inside the editor), which makes using the scroll wheel on a mouse annoying.

So, how do you think we should move forward and made it easier for organizers to customize their theme’s CSS?

#community-summit, #improving-wordcamp-org, #jetpack-css-editor, #official-websites, #user-experience, #wordcamp-org

Putting More Community in WCSF

Back in December, I proposed that instead of trying to recreate the 2012 community summit event, we try something different, and combine it with the official annual conference, WordCamp San Francisco (WCSF), for a variety of reasons (rather than restate those reasons now, I suggest re-reading that post). For the most part, people seemed to like the idea (as seen in comments), but there were a few people who did not like the idea, citing various concerns, so I tabled the discussion rather than start a big debate right before the holidays. Un-tabling!

The community summit in 2012 was an experiment on my part as to what an annual event could look like that centered on discussions rather than lectures (which fill the annual WCSF program). There were a lot of positive aspects to the event, in line with what was expected. However, there were some negative effects as well:

  • It was not intended to split the community into having to choose which annual event they attended, but that was an unexpected —and undesirable — outcome.
  • The invite-only-based-on-somewhat-subjective-factors and private nature of the event, while kind of awesome for those who were there and necessary given some of the contentious problems in the community at that time, was non-open and alienating to those who weren’t invited, the antithesis of the WordPress project’s stated values.  ← This one’s really, really important.
  • Quite a number of people who normally went to WCSF did not go after going to the summit due to the need to limit the number of trips they took.

To that end, I’m proposing that instead of organizing another retreat-based, invite-only event at a separate time/place than the annual conference, we expand the annual conference to be more than just lectures. As I handed the WCSF planning mantle off to Andrea Middleton in 2012, I’ve been talking with her and Matt Mullenweg about how we could improve the WCSF event to incorporate some of the good things from the 2012 summit to make WCSF a true annual community event. Here’s the proposal:

  • Instead of doing a full contributor day at the Automattic office as we have in the past, do a contributor series in the downstairs room at Mission Bay on the 2nd programmed day (Sunday) while blogger-centric content is on stage upstairs (with a break for all to see Matt do SOTW).
  • Add an open source project community conversations day in addition to the lecture-driven days. Have a separate registration like with previous contributor days and use advance communication to make it clear this is aimed at professionals/contributors rather than casual users, but don’t use an application process with rejections. This could be either before or after the programmed days, though am leaning toward after.

With these two changes, WCSF would be the same amount of time it has been for years — 3 days — but would have more interactivity built into those days for people involved with the project than we’ve had in the past.

In addition, I would have us set up an extra 2 days for contributor teams to work together and talk about their goals, and to talk to other teams. Needless to say, this would be optional, but anyone deemed necessary to the team should be able to attend regardless of finances via the scholarship program. This brings us to 5 days. Both Andrea and Matt were amenable to this plan for WCSF this year — knowing that whatever we do this year we will learn from and iterate on in the future — so I’d like to address the concerns raised by Siobhan and others.

  • A week is too long, people will burn out. Yep, it’s a long time! We’re talking about 5 days, not 7, but even so, it is more than a weekend (though people just interested in the csummit-style conversations, not the contributor team working days, would still be at only 3 days like always). That said, I surveyed 2 dozen other open source project and industry conferences, and 5 days was actually pretty average. Events like OSCON and SXSW lasting 5 days is an overwhelming week, to be sure, but in this case, since our formats would be shaken up every day or two, and the contributor days are basically chill co-working time, I think it will be manageable. When we used to do core team meetups, those were always a week. Coming to a 2-3 day event for people flying from very far away is also exhausting, so either way there’ll be some people who are less comfortable based on length of event. For the record, I get overwhelmed at events myself. I try to fake it, but ask Matt the number of times I’ve texted him from an event citing anxiety, or been caught reading a book on kindle for iphone in an afterparty corner. I’m not exempt from the burnout concern, and take it seriously. Also, people can always retreat away from the events as needed to take care of themselves (as long as it’s to take care of themselves, and not just because they’re hung over. 🙂 )
  • People coming in early will feel left out. Based on feedback, the idea would most likely be to do the unconference and contrib days after the regular Mission Bay event. No one would be turned away for the unconference, so that “not welcome” thing would not be an issue. For the contributor team days, by then we’d be getting to midweek, so it would be unlikely for a lot of extra people to still be hanging around town, but in any case, we can let each team decide who should be there for that.
  • San Francisco is expensive. Yes, it truly is. The cost of SF lodging is high, but when compared to flights + airport transfers for two separate events, in most cases it’s a wash. In any case, most of the people concerned have employers foot the bill or would be eligible for a travel scholarship. The travel scholarships worked really well at the summit, and while yes, Tybee was cheap and I got us some great discounts there, we have the money to cover SF travel for those who need it.
  • We can’t discuss issues with WordCamps/WCSF if it’s at WCSF because Andrea is the organizer. I think we can all be grownups, and I know that Andrea is always up for suggestions to make the program better.
  • Using Automattic’s space is a conflict of interest. I don’t know if we’d even stick with that space for everything (renting a place with multiple rooms might be better), but I disagree with this idea. The Automattic space is used for open events all the time, and again, we’re all grownups. If we do use the space I personally guarantee that freedom of speech re Automattic would be there, no one needs to censor themselves. The people that censor themselves about that stuff do it wherever Matt is (it even happened at the summit, frankly), the room is not the real issue.
  • Time Zone not EU-traveler friendly. Would I love it if the annual conference moved each year so the burden could be better distributed? Yes, and this could be a step toward that goal if it goes well. In the meantime, skewing US isn’t about ethnocentrism, it’s about numbers (majority) of contributors and businesses based in in the western hemisphere, and the 1-trip-vs-2-trips thing.
  • USA is not visa-friendly for some countries. This is definitely true. I’m ready to start working now with people who were rejected in the past, as well as with the consulate to try and get a couple of key people here. But there will undoubtedly still be a couple who don’t make it for one reason or another. This sucks, and we’d work as hard as we could to get people here who should be. Moving the annual conference in the future to a new place each year (a la Drupalcon) would address this if we can make it happen in the future, but so does having other big events like WC Europe, which wound up functioning last year as kind of a counterpart to the SF event.
  • Ignores the things team reps cited as summit must-haves at the post-wcsf dinner last year. Yep, some of them. I was one of the people who thought those things were must-haves, too (like a cozy location that enables random conversations, a size limit, etc), but when I sat down to think about the goals of the summit (and the overall project) and what was necessary vs what was enjoyable, I had a hard time justifying  the tradeoffs. Anyone can organize an offsite retreat for an invite-only group, but unless it is just for a specific level of contributors, I don’t think it’s appropriate for the project to do so because otherwise the criteria for inclusion would necessarily be at least somewhat subjective.

At the very least, I think it is worth trying it this way; if it feels like there’s a still a big hole after the event, we can revisit. That said, this is what I think is right for the project, and where I think the energy should be focused right now re annual events. If someone else believes an invite-only retreat-style event is necessary for the project’s success, I wouldn’t stand in the way of someone else taking that on and pitching their ideas to Matt.

We can discuss this proposal in the team chat today.

#community-summit, #contributor-meetup, #events-2, #wcsf, #wcsf2014