Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accepting talk proposals on github #39

Open
JuanCaicedo opened this issue Jan 3, 2016 · 14 comments
Open

Accepting talk proposals on github #39

JuanCaicedo opened this issue Jan 3, 2016 · 14 comments

Comments

@JuanCaicedo
Copy link
Member

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?

@JuanCaicedo JuanCaicedo changed the title Accept talk proposals on github Accepting talk proposals on github Jan 3, 2016
@AimeeKnight
Copy link

@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
Copy link
Contributor

@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
Copy link

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
Copy link
Contributor

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

@joshfinnie
Copy link
Member

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
Copy link

danpaz commented Jan 4, 2016

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
Copy link
Member Author

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
Copy link
Contributor

@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).

@danmactough danmactough reopened this Feb 2, 2016
@JuanCaicedo
Copy link
Member Author

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
Copy link
Member

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
Copy link

+1

@jonathana
Copy link
Member

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.

@danmactough
Copy link
Contributor

Great points @jonathana

@JuanCaicedo
Copy link
Member Author

I forked the CharmCityJS repo and updated the README a little. I changed most things, but there's a few missing (like making google form for private submissions). PRs welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants