Use CFP repo as an example of the sheetsee.js/Google Forms submissions from users

[hackygolucky]

We'd like to test out using Google Forms to allow for easier submissions of CFPs, speakers, and events.

Would love to see this succeed so we can use it for other repos such as node-meatspaces, which in future form would potentially look like knode/events on knode.io

[kennethormandy]

So everything submitted should be public, right? I cobbled together a pretty simple commenting thing with Harp and tabletop.js that did this (I realised I didn’t actually need sheetsee in that case, everything I was using was in tabletop) that took Google Form submissions, then displayed them all on the static site. Is that the sort of thing you’re looking to do?

[gergelyke]

Is it a good idea? I mean, the Node community uses GitHub heavily, it shouldn't be a problem to send a PR (takes no more than 1 minute to add a new event to node-meatspace)

[kennethormandy]

That’s a good point. If submissions were just going to be Markdown files or something, that would let people who use GitHub (like you say, probably most people) to submit a pull request. If we still wanted to provide an option for a less GitHub-familiar audience, a form could probably create a Markdown file in the same repo with the GitHub API, rather than needing the Google Forms stuff.

[mikeal]

I just used GitHub Issues for JSFest and it's working tremendously.

https://github.com/mikeal/jsfest2014-cfp

[hackygolucky]

This was mostly for testing purposes. A few of us were curious about this
workflow and wanted to test it out -just- on the CFP section for now.

In other organization stuff, I find GH Issues to be awesome. The submission
process for JSFest through Issues was a fantastic idea. At PDXNode, we've
moved to that workflow for requesting talks and speakers submitting their
proposals as well.

On Mon, Jan 20, 2014 at 9:56 AM, Mikeal Rogers notifications@github.comwrote:

I just used GitHub Issues for JSFest and it's working tremendously.

https://github.com/mikeal/jsfest2014-cfp

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-32782094
.

[mikeal]

One limitation of the "GH Issues as CFP" workflow is that all submissions are public by default. I've run several events where that wouldn't work. I've also heard people express concerns about getting more diversity with public CFPs, especially w/ comments allowed, because it creates a potential social barrier to submission. In fact, the female submission rate to JSFest was quite low, luckily I had already planned on inviting some women to speak that I was particularly interested in hearing.

[mikeal]

Hrm.... this thread has me thinking a little.

The meetup data in the meetup repo is organized by event but in some cases, like this one, you really want to collect information about an aspect of the meetup (CFP, sponsorship, etc).

I would love to see a list of different ways to do CFPs with the tradeoffs, and some sample code that does Google Forms -> Sheetsee would be super helpful.

[hackygolucky]

Sounds like a good article for us to get up as content on the site :)
Filing an issue now.

On Mon, Jan 20, 2014 at 10:13 AM, Mikeal Rogers notifications@github.comwrote:

Hrm.... this thread has me thinking a little.

The meetup data in the meetup repo is organized by event but in some
cases, like this one, you really want to collect information about an
aspect of the meetup (CFP, sponsorship, etc).

I would love to see a list of different ways to do CFPs with the
tradeoffs, and some sample code that does Google Forms -> Sheetsee would be
super helpful.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-32783234
.

[chrisdickinson]

CFP was going to be a test drive of the "google forms" mechanism for other inputs. The metrics we're looking to improve in this case are:

• Can we make high-volume, ephemeral inputs easier for organizers to process (measured in terms of time spent by the organizer)?
• Can we make high-volume, ephemeral inputs faster (measured in time between submission and having it approved)?
• How much value does it add to be able to structure data up front (measured in terms of organizer time spent correcting submissions to meet format)?
• Can we passively eliminate submissions that don't match the theme by limiting incoming topic choices -- i.e., how do we mitigate the fuzzy line between Node content, JS content, and general dev content? With meetups that's a bit more cut-and-dry -- for now it's just "node meetups" -- but with events / CFPs, that gets a bit more difficult; curation comes into play, and combining that with an unmoderated comments thread seems like it could get unruly very quickly.

---

The boons of anonymous submission hadn't really come up for the CFP/events repos since usually those are being submitted by organizers, but almost certainly will come up for other information we want to start to collect in the future.

It would be interesting to collect the CFP process for various meetups -- that information is at least partially available through the process section of each individual meetup object. knode/meetups is a requireable module that presents meetups as structured json data, and you should be able to pull that info out like so:

var concat = require('concat-stream')
require('knode-meetups').pipe(concat(function(data) {
  data[0].process // <-- should contain event process info, ideally including CFP process
})

---

Questions:

Should we formalize asking for CFP info in the meetups repo under another section?
Do we want to catalogue CFP styles and their tradeoffs in this repo?

[mikeal]

My biggest concern with formalization is that any structure will limit, in some way, the kind of content that can be submitted/requested.

Here's an anecdote about the dangers of structure:

I wanted to reach out to Mozilla to get them involved in JSFest. I didn't want to request a speaker or sponsorship I just wanted to have conversation with one of the dozen people that work in Developer Relations and see if we could create some additional events around current efforts at Mozilla like FirefoxOS.

I was told that any request for anything whatsoever must go through this form https://www.mozilla.org/en-US/press/speakerrequest/ . I know people in Developer Relations, but they can't talk to me about anything until I submit something through this form.

The form doesn't allow me to ask the question I want to ask at all. It formalizes the communication to the point where Mozilla can't really involve itself with anything but traditional events and can't have a better relationship with organizers than "we give you speaker/sponsor."

I used to work at Mozilla. I love Mozilla, and when I get frustrated i get super caremad and kinda flipped out while dealing with this form (I filled it out once and it didn't work and on the second attempt I kinda lost it) and sent an enraged email to a friend who was not responsible for this form and most likely agrees with me and was in the unfortunate position of trying to help me. Many apologies later I think she might have forgive me.

In short, structured forms ruin friendships :P

But you can see how structuring communication with your community can also restrict the intimacy, creativity and ultimately the relationship you're able to have with them. I know that some people internally at Mozilla love this form and similarly oppressive forms in bugzilla because it ends up being a filter and only people willing to put up with it make it through, the flipside is that you aren't hearing at all from all the people who won't, many of which aren't trolls they just aren't willing to put up with your forms.

I've seen forms that have a dropdown for what slide software you'll be using. Great idea, streamlines the requirements on AV, but how does the guy who wants to talk about hacking the NES submit his talk where he intends to give the whole presentation on the NES using a powerglove?

You can see where I'm going. These are some pretty extreme examples but the structure encourages a certain amount of conformity which perpetuates similar content delivery, this eventually leads to a culture of conferences that are boring and homogenous. O'Reilly has a very standardized process for all of its conferences and the result is that they are all pretty much the same. I would hate it if something like that happened to the community conferences.

[hackygolucky]

"In short, structured forms ruin friendships :P" LOL.

On Mon, Jan 20, 2014 at 2:58 PM, Mikeal Rogers notifications@github.comwrote:

My biggest concern with formalization is that any structure will limit,
in some way, the kind of content that can be submitted/requested.

Here's an anecdote about the dangers of structure:

I wanted to reach out to Mozilla to get them involved in JSFest. I didn't
want to request a speaker or sponsorship I just wanted to have conversation
with one of the dozen people that work in Developer Relations and see if we
could create some additional events around current efforts at Mozilla like
FirefoxOS.

I was told that any request for anything whatsoever must go through this
form https://www.mozilla.org/en-US/press/speakerrequest/ . I know people
in Developer Relations, but they can't talk to me about anything until I
submit something through this form.

The form doesn't allow me to ask the question I want to ask at all. It
formalizes the communication to the point where Mozilla can't really
involve itself with anything but traditional events and can't have a better
relationship with organizers than "we give you speaker/sponsor."

I used to work at Mozilla. I love Mozilla, and when I get frustrated i get
super caremad and kinda flipped out while dealing with this form (I filled
it out once and it didn't work and on the second attempt I kinda lost it)
and sent an enraged email to a friend who was not responsible for this
form and most likely agrees with me and was in the unfortunate position of
trying to help me. Many apologies later I think she might have forgive me.

In short, structured forms ruin friendships :P

But you can see how structuring communication with your community can also
restrict the intimacy, creativity and ultimately the relationship you're
able to have with them. I know that some people internally at Mozilla love
this form and similarly oppressive forms in bugzilla because it ends up
being a filter and only people willing to put up with it make it through,
the flipside is that you aren't hearing at all from all the people who
won't, many of which aren't trolls they just aren't willing to put up with
your forms.

I've seen forms that have a dropdown for what slide software you'll be
using. Great idea, streamlines the requirements on AV, but how does the guy
who wants to talk about hacking the NES submit his talk where he intends to
give the whole presentation on the NES using a powerglove?

You can see where I'm going. These are some pretty extreme examples but
the structure encourages a certain amount of conformity which perpetuates
similar content delivery, this eventually leads to a culture of conferences
that are boring and homogenous. O'Reilly has a very standardized
process for all of its conferences and the result is that they are all
pretty much the same. I would hate it if something like that happened to
the community conferences.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-32805446
.

[hackygolucky]

And besides the lol, well said @mikeal

I'm interested in making people willing to submit/share this information
have to do as little work as possible. Your counterpoints, however, are
valid.

Thoughts...

On Mon, Jan 20, 2014 at 3:04 PM, Tracy Abrahms tracyhinds@gmail.com wrote:

"In short, structured forms ruin friendships :P" LOL.

On Mon, Jan 20, 2014 at 2:58 PM, Mikeal Rogers notifications@github.comwrote:

My biggest concern with formalization is that any structure will
limit, in some way, the kind of content that can be submitted/requested.

Here's an anecdote about the dangers of structure:

I wanted to reach out to Mozilla to get them involved in JSFest. I didn't
want to request a speaker or sponsorship I just wanted to have conversation
with one of the dozen people that work in Developer Relations and see if we
could create some additional events around current efforts at Mozilla like
FirefoxOS.

I was told that any request for anything whatsoever must go through this
form https://www.mozilla.org/en-US/press/speakerrequest/ . I know people
in Developer Relations, but they can't talk to me about anything until I
submit something through this form.

The form doesn't allow me to ask the question I want to ask at all. It
formalizes the communication to the point where Mozilla can't really
involve itself with anything but traditional events and can't have a better
relationship with organizers than "we give you speaker/sponsor."

I used to work at Mozilla. I love Mozilla, and when I get frustrated i
get super caremad and kinda flipped out while dealing with this form (I
filled it out once and it didn't work and on the second attempt I kinda
lost it) and sent an enraged email to a friend who was not responsible
for this form and most likely agrees with me and was in the unfortunate
position of trying to help me. Many apologies later I think she might have
forgive me.

In short, structured forms ruin friendships :P

But you can see how structuring communication with your community can
also restrict the intimacy, creativity and ultimately the relationship
you're able to have with them. I know that some people internally at
Mozilla love this form and similarly oppressive forms in bugzilla because
it ends up being a filter and only people willing to put up with it make it
through, the flipside is that you aren't hearing at all from all the people
who won't, many of which aren't trolls they just aren't willing to put up
with your forms.

I've seen forms that have a dropdown for what slide software you'll be
using. Great idea, streamlines the requirements on AV, but how does the guy
who wants to talk about hacking the NES submit his talk where he intends to
give the whole presentation on the NES using a powerglove?

You can see where I'm going. These are some pretty extreme examples but
the structure encourages a certain amount of conformity which perpetuates
similar content delivery, this eventually leads to a culture of conferences
that are boring and homogenous. O'Reilly has a very standardized
process for all of its conferences and the result is that they are all
pretty much the same. I would hate it if something like that happened to
the community conferences.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-32805446
.

[mikeal]

Yeah, that's what I liked about using GH Issues, it was just a big text box they could do anything with, but they have pretty formatting options with markdown and can link to relevant repos and Issues to tie their talk in to what is happening on GH. It made for a good range of submissions:

jsfest/sf-cfp#74
jsfest/sf-cfp#29
jsfest/sf-cfp#15

[chrisdickinson]

@mikeal good point(s)! The concerns a form -- with regards to accepting events to a repo/catalogue -- would potentially alleviate for me are:

1. Throughput -- Knode in general has a "get two +1's from organizers to merge" system. I like that this gets multiple knode organizers to look at any incoming information. As we get more repos, I am afraid that this will not scale, causing frustration for contributors and organizers alike. The alternative is that we could abandon that approach -- or abandon it for specific repos -- which might have its own drawbacks.
2. I'm (maybe unnecessarily) worried about the potential of a public flamewar on github issues over the acceptance or denial of a given event (based on "this isn't about node" grounds). In reality, maybe trying to solve that before it happens is unnecessary (or even bad!) It could be a healthy discussion, after all, that lets folk modify what events are accepted / unaccepted. On the other hand, a bad flamewar can fatigue organizers and make folks lose faith in the project.

The form stuff has been brought up here, in the CFP repo, as a test bed to see if we like it or not, since it's a relatively low-risk place to do so (that we can turn back into github issues-only easily).