Feature Request: Give WordCamp attendees ability to mark/save sessions of interest on camp schdeule

Attending WordCamp is great, but as an attendee I have to repeatedly refer to the schedule to see which talks I wanted to go to next and which room I should be in, etc. I’d like to suggest a new feature to enable users to create a custom track from a published schedule on a WordCamp website. A way for users to select their desired session and somehow save this “custom” track or collection of sessions.

What does saving mean?

I think the MVP would be save and print or email the custom schedule/agenda. The user would select one talk (maybe more? if they’re interested in multiple sessions) per time slot to attend by clicking that slot in the schedule, and visually the schedule would highlight marked sessions. Perhaps selecting a session would even create a new list of sessions as that attendees custom agenda for the Camp and that agenda can be printed. I’m sure proper UX would deem it necessary to include some type of buttons or interface to add a session to an agenda and then to remove selected sessions too. As MVP, this could be front-end only and not even save any data. It could populate an email or be ready to print – or even simply allow users to keep the page open on their phone for quick glances during the conference.  I especially see this agenda layout being useful on mobile, where it’s tough to fit a complex schedule.

For a nicer experience though, the site would save the user’s selections and allow them to return to the schedule to see their saved/selected sessions. Ideally this would be tied to their .org account or something so either on the computer or phone they could log in and view their saved agenda.

How could it be useful to more than just the attendee?

Then if we end up being able to save this data, why not allow users to opt-in to share their schedule with other attendees or even the public. Attendees and sessions are displayed, let’s connect them. Each session abstract could indicate interest either by how many attendees have selected this talk or even list all interested attendees. I could see this being useful information to gauge general interest for talks and may help ensure to have ample space for each session. For example, if one session has a high level of interest it could be moved to a larger room to account for more attendees. Anyways, I digress…

Here I’ve mocked up a quick and ugly schedule with some marked sessions:

wordcamp raleigh schedule with marked sessions

Here’s a nasty screenshot of a schedule for WordCamp Raleigh with sessions marked as proposed. Notice there are two sessions saved at 11am, while only one session for later times.

The main point here is to have a way that when viewing the WordCamp schedule, attendees can select which sessions they are most interested in to create their own agenda during a WordCamp, and then a convenient way for users to save this agenda for quick reference during WordCamp. Sharing this interest may help attendees network and connect with others before and during the event. This data could possibly provide general feedback to organizers for planning purposes too.

I don’t believe this is the first time this type of idea has come up and I’ve had positive feedback from others and hope this can generate a useful discussion and roadmap. Thoughts?

#improving-wordcamp-org, #wordcamp-org, #wordcamps #feature-request

Remote CSS Plugin Launched on WordCamp.org

The Remote CSS tool is now available on WordCamp.org. It’s one of the ideas that came out of last year’s Community Summit, and it allows WordCamp.org site developers to work with whatever tools they want, instead of Jetpack’s CSS editor.


What You Can Do

For instance, you can:

  • Work in a local development environment, like Varying Vagrant Vagrants.
  • Use your favorite IDE or text-editor, like PhpStorm or Sublime Text.
  • Use SASS or LESS instead of vanilla CSS.
  • Use tools like Grunt to automate your workflow.
  • Manage your CSS in a version control system like Git.
  • Collaborate with others on a social coding platform like GitHub.

You can use all of those tools, only some of them, or completely different ones. It’s up to you how you choose to work.

How It Works

Remote CSS works by downloading your CSS file from a remote server (like GitHub.com), sanitizing it to remove security threats, minifying it, and then storing a local copy on WordCamp.org. The local copy is then enqueued as a stylesheet, either in addition to your theme’s stylesheet, or as a replacement for it. The local copy of the CSS is synchronized with the remote file whenever you press the Update button, and you can also setup webhook notifications for automatic synchronization when the remote file changes.

Because of security concerns, it can only support specific hosting platforms, but it currently supports GitHub, and we can add others if there’s interest. If you want to use Beanstalk, Bitbucket, CodeForge, or something else, let me know.

Contextual Help

The plugin also contains detailed setup instructions inside wp-admin; just open the Help tab.


It plays nicely with Jetpack, so you can test it out today without losing any of your current CSS.

If you’re looking for something simpler, though, Jetpack’s CSS Editor is still a great option.

If you have any feedback or ideas to improve it, please leave a comment. If you’d like to check out the source code, it’s available in the Meta repository.

#git, #improving-wordcamp-org, #jetpack-css-editor, #official-websites, #wordcamp-org

Update on building a new WordCamp theme

This is a follow up to the @iandunn post on the WordCamp.org tools survey results.

I setup a Github repo for the new WordCamp theme with a fork of Underscores to get things started.

To start with I have been collecting feedback and ideas for a new WordCamp theme so that our design lead, @robertnienhuis, has something to work with. I haven’t gotten too much feedback online yet, but have gotten some good ideas from several other organizers offline. If you would like to share some feedback as well please post a comment below!

Theme Features

Here is the feedback that I have collected so far, as well as my own ideas:

  • Great Design: I would like to keep the theme light and minimalist, easy to build on, but also have it look good enough out of the box for a WordCamp without a strong designer to be able to use as-is.
  • Mobile First: I’d really like to include a strong mobile version that makes WordCamp sites easy to use at the event when you are on the go.
  • Widgetized: It’s always tough to get markup where you want it, I’d love a lot of widgetized areas so I can get the content I need in the right spot to match any design. I spoke with some other organizers who would also like more widgetized areas, sitewide and page specific. Particularly for the featured content sections typically found on a WordCamp site.
  • Widgets: Building actual widgets into the theme might be a step too far, but there was some interest in having a few featured widget styles built in, so that if you used the right markup in a text widget you could get a good looking featured section right out of the box that organizers can expand on from there.
  • Page Templates: Most of the people I talked to were interested in having more page templates to choose from. Like a homepage template with a page content area and multiple widget areas for featured content and also a similar homepage template with a smaller blog area setup as recent posts with excerpts. We’ll need a single column page template of course, but I’d also like to try to include a more minimalist template with little or no header or footer as well that people can use for whatever they want as a blank canvas.
  • 404 Template: I’d like to include a pretty minimalist template for this too that includes a widget area just for the 404 page, so that people can create a nice custom 404 page if they want to.

Website Examples

I also have a few examples of WordCamp sites that I like, please share your favorites in the comments!

  • WordCamp Minneapolis: Westwerk did an awesome job designing this site and if we can do half as good I’d be thrilled!
  • WordCamp Montreal: They had a sharp looking site this year, I really like the call to action block on the homepage below the header with the tickets/schedule spot, and the subscribe/ social media spot.
  • WordCamp Denver: A nice clean site, great for mobile, with a sweet camping vibe.

I’m pinging people that volunteered to help out in the previous post: @cheffheid, @valeriosza, @dnelle, @danielgcarvalho, @brettshumaker, @davidjlaietta

#improving-wordcamp-org, #official-websites, #themes, #wordcamp-org

Site Cloner v1 is now available

The first tangible outcome of the Improving WordCamp.org project is now available. The Site Cloner lets you browse through screenshots of other WordCamp sites, and then easily copy the custom CSS from them, so that you don’t have to start a new site from scratch.

Screenshot of Site Cloner

Props to @ryelle for building the prototype 🙂

If you’d like to check if out, just open up the Customizer on your site and click on the Clone Another WordCamp panel. Just be sure to not click the Save button, though, unless you actually want to switch your theme and reset your CSS 🙂

It’s the first version, so there are some known bugs and missing features. If you’d like to help out with those, check out these issues on Meta Trac:

It’s also important to keep in mind that there will always be some CSS that is specific to each site; maybe it references a page ID, or uses a background image with the original Camp’s logo, etc. So, you’ll still need to do some work to make the CSS fit your site, but this should get you 90% of the way there.


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, @iandstewart, @miss_jwo, @topher1kenobe, @jenmylo, @georgestephanis, @valeriosza, @jb510, @jleuze, @robertnienhuis, @cheffheid, @dnelle, @danielgcarvalho, @brettshumaker

#improving-wordcamp-org, #official-websites, #wordcamp-org

Better WordCamp.org Docs

One of the projects we identified to improve WordCamp.org was to have better documentation.

Sometimes organizers aren’t aware of the intended approach to building a WordCamp site, or of the tools that are available, so they end up doing things the hard way, or in a way creates a worse experience for participants.

For example, if an organizer doesn’t make use of the custom post type for speakers, then those speakers won’t get a badge on their WordPress.org profile, and the upcoming Android app won’t be able to display speakers for that camp.

We do have a lot of written documentation on plan.wordcamp.org, along with some videos, but there are many ways that it falls short.



Here are a few of the problems we’ve already discussed, but please leave comments with any others that you see.

  • There’s a lot of documentation, and most people won’t read through everything.
  • Organizers have to visit an external site to reference things while working on their WordCamp site.
  • We’re always adding new features and iterating on old ones, but there isn’t a good way for returning organizers to know what’s changed since they used the site last year.
  • Building a site on WordCamp.org is different than what most organizers expect, so they need to shift their mindset in order to not fight against the grain. For example, organizers can’t upload custom plugins or create child themes; the majority of customization is done with CSS and our custom tools.

Brainstorming Solutions

Here are a few ideas, but please add more in the comments, and leave your feedback on these.

  • Bring documentation into wp-admin, in the form on Contextual Help and Admin Pointers.
    • Should we bring all documentation into wp-admin, or just certain types (like cheat sheets)? If everything is in wp-admin, it will be hard to get an overview. Maybe a hybrid approach?
    • We should probably create a new “WordCamp.org Help” contextual tab rather than integrating into Core’s generic “Help” tab, because that would be more discoverable and less cluttered.
    • Duplicating documentation in multiple places would be harder to maintain, and they’d likely get out of sync.
    • Hard-coding documentation into a plugin (rather than the current WordPress pages) would make it impossible for non-developers to update and improve the documentation, which would be a bottleneck. Maybe we should build a way to programmatically import documentation from Plan into wp-admin? It might need to be pages specifically crafted for wp-admin screens, though, rather than the kind of lengthy articles we have now.
  • Add more videos, because sometimes those are easier to digest than long articles.
    • Are there specific types of content that are better for video than others?
    • Would this have a negative impact on non-English speakers?
  • Encourage organizers to ask questions in #events on Slack when they don’t know something, and when they’re not sure if there’s a better way to do something?
  • Create an demo site that is “perfect”, and then make a video walking through it, showing the best way to set things up.
    • We could also give organizers read-only access to it, so they could explore and play around.
  • Make the system more intuitive, so that formal documentation is less necessary.
    • For example, we currently pre-populate new sites with default pages to provide examples of common content and shortcode usage.
    • What other things could we do?
  • Create a page that has an index of all the significant changes since their last camp. Organizers could visit the page and enter a date range, then get a short description of all the changes, with links to their full documentation.
    • One downside to this it would require extra time from developers, each time they make a change, and we already have limited time. It might be possible for volunteers to do a lot of it, but it’d still require extra developer time to inform the volunteers about it and give them all of the information they’d need to document it.
    • Another idea would be a mailing list where a message gets sent out each time something new is released. A big downside to that, though, would be that organizers would probably forget most of the info by the time their next camp rolls around.
    • Another idea would be to create a video once a quarter that walks through all the changes in the past three months. This has the same drawback as the original idea, but it might be a better format, and doing it once a quarter might be easier doing it than every time a change happens.

What are you thoughts on all of that? What other problems and solutions do you see?


Everyone is encouraged to participate 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, @iandstewart, @miss_jwo, @topher1kenobe, @jenmylo, @georgestephanis, @valeriosza, @jb510, @jleuze, @robertnienhuis, @cheffheid, @dnelle, @danielgcarvalho@brettshumaker

#documentation, #improving-wordcamp-org, #official-websites, #wordcamp-org

Results from the WordCamp.org Tools Follow-Up Survey

The results of the previous survey were unclear about the theme/template question, so I created a new survey to clarify that. The results from that follow-up survey are now in.

The most popular choice was to let organizers build a new theme to meet the specific needs of WordCamps. We’ll also be able to add new page templates to the theme in the future, provided that they meet the criteria discussed earlier.

Once the theme is done, it’ll be reviewed by the Meta team for any security issues, and by the Deputies for general appropriateness, and then made available to everyone on WordCamp.org.


Building a Team

The first step will be to put together a team of organizers who want to build the new theme. Obviously it should have designers and developers, but it could also benefit from UX and accessibility specialists, and of course lots of people to test it.

If you’re interested in being on the team just leave a comment below, and if you know someone who may be interested, please send them a link to this post.

We’ll need someone from the team to take the lead role, and make sure everything is organized and moving forward. Once we see who’s on the team and what everyone’s skills are, I’ll look for someone who’d be a good fit for that.



The team will have the freedom to build whatever they think is best, but I think we should also agree on some guidelines to ensure the project reflects our community’s values and standards.

  • The team should be welcoming and open.
    • It should be a collaboration from across the community, rather than a small group from one city or company.
    • In practical terms, that means development should occur on an open platform like GitHub, and communication should take place on this p2 and in the #events channel on Slack.
  • The theme should serve the many, not the few.
    • The goal should be to make something that meets the needs of most organizers, rather than just the needs of the individuals on the team.
    • The focus should be more on making it a flexible starter theme for organizers to customize, rather than just something that looks beautiful when it’s first activated. It can (and should) have a great initial design, but the primary goal is to let organizers take it and easily create something that looks totally different.
    • The team should solicit feedback from lots of camps to make sure that their needs are addressed.
  • The project should not be a design-by-committee.
    • Input from organizers and contributors should be weighed heavily, but ultimately the team lead should be the one making the final decision on what choices will have the best outcomes for the entire community.
  • The theme should meet the relevant standards:
  • It should be a theme only.
    • It shouldn’t bundle custom post types, shortcodes or other functionality.
    • Having said that, the team should feel free to contribute as much as they’d like to the existing plugins, provided those contributions will also work with the other themes on WordCamp.org.
  • It should be thoroughly tested.
    • Because it will be customized by lots of organizing teams, we’ll need to maintain backwards compatibility, which will limit the kinds of changes that can be made in the future. That makes it very important to test well up front.
    • “Testing” in this case doesn’t just mean testing the theme’s internal correctness, but also testing how easy it will be for other organizers to create new designs on top of the theme.
    • It should be beta-tested with a handful of camps before launching to everyone. If fixing any problems are found during the beta period that would require breaking backwards compatibility, then we’ll be able to do that and manually update the beta sites.

If anyone thinks there should be any changes to those guidelines, please leave a comment so we can all discuss it.


Everyone is encouraged to participate 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, @iandstewart, @miss_jwo, @topher1kenobe, @jenmylo, @georgestephanis@valeriosza@jb510


#improving-wordcamp-org, #official-websites, #wordcamp-org

Editing WordCamp CSS Locally with Git

One of the Improving WordCamp.org projects is to let organizers develop their CSS locally, and then commit it to a version control system like Git, and have it automatically updated on their WordCamp.org site. This is the project that I think will make the most impact for organizing teams with experienced developers.

The benefits are that:

  • You avoid all of the pain points of editing CSS in a browser.
  • You can use whatever IDE and other tools that you normally use.
  • You get all the benefits of a version control system, like easier/safer collaboration, history, and a structured approach.

So, I’d like to discuss the best way to implement a system like that.

Implementing a solution

After thinking about it for awhile, this is the best approach I’ve come up with:

(Note: This process has been updated since it was originally published, to incorporate feedback from the comments.)

  1. Add a new wp-admin screen under the Appearance menu, called something like “Remote CSS”. It will have a field where you can enter the URL for a CSS file, and a button to pull CSS from that repository and enqueue it locally. The CSS file can be in a source control repository like Git, but it doesn’t have to be.
  2. The CSS file can be named anything, and it can be built from supporting SASS/LESS/etc files, but only the CSS file will be used by WordCamp.org; everything else will be ignored.
  3. The contents of CSS file will be passed through Jetpack’s CSS sanitization functions, and if there’s anything left, the safe CSS will be cached. If there are any errors while fetching the file, the process will abort to avoid overriding the known-good version that’s already stored on WordCamp.org.
  4. When front-end pages are loaded, the cached CSS will be enqueued as a extra stylesheet, similar to how Jetpack’s Custom CSS is enqueued.
  5. To automate updates, there will also be an endpoint listening for webhook notifications of pushes to source control repositories. If the files changed in the pushed commits include the CSS file, the plugin will automatically fetch the latest version, sanitize it, and cache it. Updates will be limited to once every 3 minutes, to prevent abuse. Rate-limited notifications should be queued and acted on once the limit has expired.
  6. If the fieldon the Remote CSS screen for the CSS file is empty, we’ll display step-by-step instructions for setting up the CSS file, webhook, and a local WordCamp.org sandbox. If the file is hosted on GitHub, we’ll also recommend enabling two factor authentication, to mitigate the risk of a compromised account leading to CSS defacement or other malicious changes.
  7. A new meta box could be added to the Appearance > Custom CSS page to advertise the option of using a remote repository.

Does anybody see any problems with that approach, have a different idea, or have any other feedback?


#git, #improving-wordcamp-org, #jetpack-css-editor, #official-websites, #wordcamp-org

Allowing Custom PHP and JavaScript on WordCamp.org

By far the most common request in the WordCamp.org tools survey results was for the ability to write custom PHP and JavaScript. This is definitely understandable, because being limited to only modifying CSS does significantly restrict what you can do with your site.

Why not allow custom PHP and JavaScript?

The reason that this restriction exists is because there would be very serious security and maintenance implications if we were to open things up.

Security is very hard, even for experienced developers. Everybody makes a mistake at least occasionally, and many developers don’t realize how often  they do.

There’s no doubt that allowing unreviewed PHP or JavaScript would introduce critical vulnerabilities, not just to WordCamp.org, but to the rest of the WordPress.org infrastructure as well, and even to regular WordPress sites interacting with the infrastructure.

WordCamp.org is connected to the rest of WordPress.org in several key ways, and the right kind of vulnerability (or combination of vulnerabilities) could allow an attacker to do some pretty scary things, like silently stealing password hashes or authorization cookies. If they targeted someone with commit access to Core, WordPress.org, or a popular plugin, then the results would be severe.

Of course, we have access controls, monitoring, and other systems in place to minimize the chance of an attack and mitigate its effectiveness, but the essential threat is there and can’t be downplayed.


Why not just review custom code before it’s committed?

We just don’t have the resources to review that much code. There are only two developers who handle the vast majority of the work on WordCamp.org, and both of us also have responsibilities on other projects. So, we have roughly the equivalent of one full time developer. There were 80 WordCamps in 2014, and that number grows every year.

Conducting a thorough security audit and code review takes a significant amount of time, and simply isn’t possible with the resources we have.

Imagine giving hundreds of developers access to one of your high profile sites, or committing to review hundreds of themes and plugins every year while still trying to build new features and iterate on existing ones.


Other potential solutions

  • Assemble a team of volunteers to review code – Because of the security concerns, any volunteers would need to be very experienced and a trusted member of the community, and because of the volume of sites, we would need to have a lot of them. I don’t think we’d be able to keep up with the demand, and we’d also be taking those people away from contributing to other projects. It’d be much more efficient and make a bigger impact if those people collaborated on projects that could be shared between all camps instead.
  • Let everyone host their own site – This is how things were in the early days, but we moved to a centralized platform because it was common for domain names to expire, or for the current year’s team to be unable to post an announcement to the previous year’s site, or for sites to be unmaintained and get hacked, etc. It would also mean that organizers would have to spend extra time setting up hosting, and, because of security concerns, anything that requires connecting to WordCamp Central or the WordPress.org infrastructure would become much more complicated (e.g., centralized payment requests and ticket revenue collections, single sign-on, integration with Profiles.WordPress.org, etc).
  • Create each site inside an isolated, virtual container – That would require a lot of work from the Systems team, who are also very limited on resources, and it would have the same downsides as above, where anything that connects to Central or WordPress.org would become much more complicated.
  • Only let experienced developers write custom code – The security concerns would force us to set the bar very high, and evaluating a developer’s qualifications is itself a time-consuming process, so this would only impact a small number of camps. It could also make it appear like certain camps were getting special treatment, and lead to hurt feelings when someone who feels like they’re experienced enough isn’t accepted.


What makes the most impact?

WordCamp sites are tools that help organizers communicate with attendees. It’s great to have a design the community can take pride in, and working on the site can definitely be a community-building experience, but volunteer hours are limited. It’s best to focus on things that will inspire and connect attendees at the event, rather than making the website perfect.

At the end of the day, attendees will be helped the most by the sessions, workshops, networking, and contributing that goes on at the event.

The goal of WordCamp.org is to give organizing teams something that works out of the box and facilitates all of the basic conference services that most WordCamps need, so that you can spend your limited time on the event, rather than the website for the event.


Solutions that benefit everyone

Allowing organizers to write custom PHP/JavaScript isn’t the real goal, it’s just a means to an end; and I think there are better ways to get there.

For the most part, all of our camps have very similar needs, so rather than each one re-inventing the wheel on their own, it’s much more efficient if we collaborate on solutions that work for everybody.

The survey results helped us identify the worst pain points with the current tools, and we’re planning solutions to improve the CSS editing experience, to give more theme/template options to choose from, and to be able to easily clone another camp’s site instead of having to start from scratch. The feedback on all of those was that they’d have a huge impact on everyone’s ability to create the sites they want.

I think that focusing our time and energy there is going to be much better for everyone in the long term. If you’d like to help move those projects forward, please check out the survey recap for next steps.

And if there’s a project that would benefit everybody, but it’s not on that list, you can always work with the Community Team to build a consensus for it, and organize a group of developers from local communities to contribute it. You don’t have to be a developer yourself; many projects need people to organize everything, create designs, write documentation, perform user testing, etc.

#improving-wordcamp-org, #maintenance, #official-websites, #security, #wordcamp-org

WordCamp.org Tools Survey Results

The results from the WordCamp.org tools survey are in. Each PDF below has a chart with the totals, along with the anonymous feedback that was given.


Allowing Custom PHP and JavaScript

By far the most common feedback was about the desire to write custom PHP and JavaScript. That deserves to be discussed, but it’s a big enough topic that it should have its own conversation, so I started another post with a detailed explanation of the reasons behind the limitation.


How well does Jetpack’s CSS editor meet your needs?

  • A surprising number of organizers were happy with the editor (62%), but that still leaves almost 40% who aren’t.
  • The most common frustrations were losing your place when the page reloads to save changes, and having changes overwritten when multiple people are editing at the same time. Both of those were problems we identified as things to fix if we choose to focus on improving Jetpack rather than building an alternative solution.


If we were to improve the CSS-editing experience, which approach would you prefer?

  • Supporting a local development workflow was more popular by 10% (actually, a bit more if you include several of the “Other” answers that were similar).
  • I think it’s likely that the people who voted for improving Jetpack are mostly happy with the editor, but just wish it were better; while people who voted for an alternative approach aren’t really happy at all. So, improving Jetpack would make a moderate impact, but building the alternative approach would make a big one. Based on that, I think we should pursue the local development workflow.
  • Jetpack won’t be going away, of course, and it will still receive any improvements that ship with future versions. So if you’d like to see the CSS Editor issues resolved, you can still send pull requests to Jetpack, or encourage developers in your local community to do so.
  • Several people suggested we do both, and of course the two options aren’t mutually exclusive, but we do have very limited resources, so we need to prioritize the things that will make the most impact and do those first.
  • People overwhelmingly requested Git(Hub) over Subversion. I’d like to see us explore this first, since most teams are much more familiar with Git than SVN, which makes SVN more of a barrier than a benefit. I can foresee there being some logistical challenges that we wouldn’t face with Subversion, but it’s worth a shot.
  • See the Next Steps section at the end if you’re interested in helping out with this.


To have more options when customizing your site, which would you prefer?

Page templates were the favorite choice by a wide margin, but I’m worried that I didn’t word this question very clearly, and that may have skewed the results. I assumed that everyone would already be familiar with the previous discussion that contains details on the proposal, but some of the responses make it sound like some people thought that “have the ability to create custom page templates” meant that they could freely upload unreviewed custom templates, which isn’t what had been we originally discussed.

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.

To clarify, I started a new survey with just this question, but better descriptions of the answers. I also added a new option, which incorporates one of the suggestions from the survey, which was to allow a group of organizers to build a new custom theme to fit the specific needs of WordCamps, which would then be reviewed and made available to all camps.

Please take that survey to help us move forward with this project; it closes at midnight UTC on June 16th.


Several people suggested that we add more themes and custom page templates, which is an option, but unless there are enough volunteers to work of both in parallel, we’ll need to prioritize the one that makes the most impact first.

Allowing inline SVGs was another thing that was mentioned several times. WordCamp.org doesn’t actually block them, WordPress itself does. SVGs are awesome in a lot of ways, but they’re not the benign images most developers think of them as; they’re really XML applications that can run arbitrary JavaScript and embed external resources.

Once Core finds a way to safely allow them to be uploaded, though, WordCamp.org will automatically inherit the solution. In the mean time, you can still use SVGs as background images via CSS, which has most of the benefits but without the same security concerns.


Of the four projects identified in the make/Community posts, how much would each of them benefit you?

D’oh, comments were disabled for this question, that was a mistake on my part. Please leave them on this post if you’ve got any feedback.

All of them ranked pretty well, so it looks like we picked good projects. Improving the CSS-editing experience and adding more themes/templates were the most popular, followed by cloning a site and then docs.


Is there anything that would benefit you more than those 4 projects?

There were a lot of comments here, but no big themes among them, and many of them would actually be solved by the proposed projects, so I think we should stick with the ones we’ve got. This is still a good list of things to keep in mind for the future, though.


Do you have any other comments or feedback?

This one also has some good feedback, but nothing that would shift our direction.


Existing Tools You Might Not Know About

There were a handful of answers that requested tools we already have:

  • The Tagregator plugin pulls in social media posts with your hashtag from Twitter, Instagram, Flickr and Google+. Check out the “Social Media Stream” page that automatically gets created on new sites.
  • You can e-mail attendees based on discount codes and other filters with CampTix. Look for the Tickets > Tools > Notify screen.
  • You can embed live streams from Livestream.com, Ustream and DaCast using shortcodes.
  • If you use the Call for Speakers form that is automatically added to new sites, then any submissions will be automatically converted into drafted Speaker and Session posts, which can you publish or delete when you decide which ones to accept.
  • Session posts have a meta box to add URLs for the slides and WordPress.tv video. If you fill those in they’ll automatically be shown in the sessions shortcode.


Next Steps / How to Get Involved

For each of the projects, we’ll need people to help brainstorm ideas, give feedback, and write code.

  • Clone another camp‘s theme/CSS/etc: This project needs a few developers to test the prototype and report/fix any issues.
  • More Themes/custom templates: The data for this question may have been skewed, so please answer this revised question to make sure we have good data to base decisions on. Once the results from that are in, I’ll post them here and we can discuss how to move forward.
  • Local CSS development and better documentation: We’ll need to discuss the details for these and come up with a plan. Once the conversation on this post dies down, I’ll start new posts for them so that we can have a focused discussion.


#improving-wordcamp-org, #official-websites, #wordcamp-org

WordCamp Organizer Survey

We’ve had several good discussions on ways to improve the tools used on WordCamp.org, and now it’s time to collect some hard data so we can know how to move forward.

If you’ve worked with any of the WordCamp.org tools — custom post types, Jetpack CSS editor, widgets, etc — in the past 18 months, please fill out this 6-question survey:



Anyone on an organizing team who has used the WordCamp.org tools is encouraged to take the survey, but I’m pinging the people who took part in the previous discussions to make sure they don’t miss it: @ryelle, @harbormark, @chanthaboune, @nvwd@kovshenin, @rafaehlers, @davidjlaietta, @dimensionmedia, @mj12982, @iandstewart, @miss_jwo@topher1kenobe, @jenmylo, @georgestephanis, @bandonrandon@cliffseal@valeriosza@hlashbrooke@lcrddz

#improving-wordcamp-org, #official-websites, #survey, #wordcamp-org