Accepting talk proposals on github

[JuanCaicedo]

I like the idea of continuously accepting proposals through a repo the way that CharmCityJS does it. I like that because it's transparent, easy to manage, and we can get proposals when it's convenient for the proposer, instead of only when we have time to go ask for submissions. I think this will encourage more participation.

For me, submitting a talk and getting it accepted for a CharmCityJS meetup felt very easy, even as an out-of-town-er. I probably wouldn't have done it if it mean waiting for a CFP, since I wouldn't have known when it was.

It also meant that organizers and community members could contact me on that issue, so getting the talk accepted was easy as well.

One concern could be anonymity. We can provide a form for anyone who wants to submit anonymously. After they've filled it out, an organizer can convert their responses into an issue and just say that it's anonymous, instead of from themselves.

@ApeChimp or @AimeeKnight would either of you mind sharing how you chose to use github as a forum, as well as anything that you've liked or not like about it?

[AimeeKnight]

@JuanCaicedo IIRC @jasonrhodes was inspired by Brooklyn JS. As an organizer, and speaker, it was pretty easy. I like that it enabled us to go back and forth a bit before finalizing things, and I suspect it makes things easier for people submitting, since they can see a history of what's been discussed, and what's pending. I can definitely see how it might hinder someone from submitting though, in the event they were unsure on how their ideas might go over. I'd say it'd be helpful to provide contact information for that potential situation in the README. Let me know if I can help in any other way! Hopefully we can meet at Nation JS in March!

[danmactough]

@JuanCaicedo I think this may be a messaging problem: we absolutely do not require that proposals go though this CFP process (such as it is). We have encouraged people to submit (and have had people submit) proposals as issues to this repo, and had other proposals come in via Meetup.

We definitely need to take a look at our messaging though. I have not given it any thought at all, to be honest.

Could we turn this into a checklist for what we need to do to better communicate how to propose a talk?

[jasonrhodes]

So from our experience, I think a big reason it's been successful is because we funnel all proposals through the issue queue. Maybe if you do the CFP as a way to drive proposals, you could skip the Google Form and just drive people to the same issue queue? Just a thought, good luck with whatever you go with!

As for anonymity, I think we could do better about providing that option, not for keeping them anonymous forever (how could they?) but to let a person work through a topic in private, get feedback, then submit the issue when they feel better about it. Still thinking that through! :)

Lastly, we are trying to figure out how to keep the rolling form from producing stale, old entries that we haven't picked and probably want to move on from. When do you close the old submissions, and how without being a jerk? BrooklynJS closes everything every month, so it's all new submissions every month. Risky for us because we won't necessarily get enough to make that work, so I'm thinking that through still, too.

[danmactough]

Those are all good points, @AimeeKnight & @jasonrhodes. Thanks!

[joshfinnie]

I like this idea a lot. At TrackMaven we have been using ZenHub to keep our issues in order. I think it would be a huge help here if we open issues up to talk proposals.

[danpaz]

I like the idea of having an option to submit proposals via github issues, but at the same time the CFP has the advantage of being a strong call to action with a deadline, something we can announce and share on social media. Adds some motivation to potential speakers who are on the fence about submitting their talk. So I think combining the two approaches could work here, but like @danmactough said maybe we're already there and just need to refine the messaging.

[JuanCaicedo]

I guess what we've settled is we're definitely open to people submitting talks on github at anytime. Maybe we need to mention that at every event and share the link every so often so people know where to submit.

Personally, I think if we're going to discuss proposals on github anyway, it would save us some effort to have the submitter post them here directly. We can revisit that idea before we put out the next CFP though, since we're booked through May.

[danmactough]

@JuanCaicedo I'm going to reopen so we can nail down a couple of things that are still not 100% clear.

• Where should people submit proposals? To the "organizers" repo? That seems a little weird to me.
• Whatever the answer is to ☝️, I think we should update the group description on Meetup to point people to where they can submit proposals. Maybe update the Twitter profile, as well (if there's room).

[JuanCaicedo]

In Baltimore they use a separate repo https://github.com/charmCityJs/talks. That would be good since we can have a readme with a template. I can draft it out!

[joshfinnie]

I think a separate repo would be perfect. We can have a dedicated README for it and everything. I think we should copy Charm City here ;-)

[mcwhittemore]

+1

[jonathana]

Having the repo is great, but I am concerned that we make sure that in the README we indicate alternate methods to vet presentation ideas as it is very unwelcoming to some set of presenters that we might otherwise want to present talks (first-time presenters is just one example). Last meetup's talk is a good example: there was a very positive discussion involved in determining whether the talk was on point and a little bit of steering based on feedback. @mcwhittemore has spoken enough and has enough confidence in his ability to engage in the process, but someone either less familiar with the group, presenting, or who otherwise might not be receptive to input in a public forum in that way might be dissuaded from even proposing.

So, I'd like to see the repo exist, as long as a clear (and visible as in near the top and called out) alternate process for either submitting or vetting a concept is available and documented in the README.