MozFest 2015 site: Investigate using Github to organize session proposals

[edrushka]

Context: In another ticket, @iamjessklein suggested using Github to handle the proposal submissions:

My thinking is that the flow could work like this:

participants fill out the form on the festival site
the contents of the form autocomplete into a github issue with tags
mozfest staff can review and sort forms via tags
when sessions are chosen, they can be added to a track (or theme?) tag or milestone
During the week of the event, the schedule section of the site will display the schedule and then link out to the individual sessions issues
Session hosts have the option to use their github issue to update the status on their session or use it for documentation - and participants can add to it.
After the event, issues will get archived - or - if they are active.. they will act as a project management tool.

Some examples of this in use:

• Cascadia
• Brooklyn.js

@Saallen, when you speak with @thornet on Monday, can you identify the required functionality for the separate groups of users (proposers, session hosts, MozFest team) so we can investigate if this can work?

cc @ScottDowne @alicoding @simonwex @davidascher

[davidascher]

This I think may run into issues for those (many) applicants who don't already have a github account.

[ScottDowne]

I wouldn't expect people to make github accounts, that would be super annoying.

I pictured it being issues generated via a generic account we setup for this (or an existing account). All behind a small API of some sort.

However, while it's an interesting idea worth considering, I am slightly leaning towards google forms.

[Saallen]

@ScottDowne is there a way to make the back end of the Google forms not so taurmatic with 600+ proposals to sort through? This is last years backend with a formula Fuzzy fox made to separate the tracks into different tabs

[Saallen]

Hey looping @toolness as he created some voodoo magic when he transfered over loads of issues to a new repo last week. @toolness we are considereing using github as a platform to submit sessions for this years mozfest but I am worried how to migrate all the chosen sessions for the festival to be exported onto a spreadsheet for the sceduling app. Do you think this is possible?

[ScottDowne]

@Saallen no idea about formatting for google forms.

I think time is going to be the leading factor as to why I want to use google forms over github.

[toolness]

Ah, you mean the The Great Learning Issue Migration!

Hmm, it's definitely possible to export GitHub issues to a spreadsheet, but there's a question as to how to do it in a rigorous way. What fields should the spreadsheet have, and how should the GitHub issue fields "map" to those spreadsheet issues? If that mapping is straightforward then it shouldn't be too hard.

Also, the situation will become really complicated/impossible if you want to actually sync information between a spreadsheet and GitHub rather than merely export, i.e. if you want to tweak the spreadsheet and then mirror those changes back to GitHub. This might seem obvious but I just want to make sure you know it's only easily doable as a one-way operation.

[ScottDowne]

Looking at Sched, it has an import API, meaning it can go directly from github issues to Sched without ever being in a spreadsheet.

That is going to require some code to export/import it, but that would be needed to convert to a spreadsheet anyway.

@Saallen Would sorting through 600+ proposals directly with github issues be easier than a spreadsheet?

[Saallen]

@ScottDowne I am limited with my Github ninja skills but I think if we can sync the call for proposal tag options to labels within github then I imagine we can filter easily.
@toolness we would not want to migrate back to github.
Would you both be free for a call tomorrow to chat about if this could actually work, what we would need to do and if it was worth the work? I would love to bring some Space Wrangler gurus into the call too and get their reaction as they would be the team living in Github for the festival lead up.

[ScottDowne]

@Saallen The biggest downfall for using github issues is it's more work, not a unreasonable amount, but considerably more than google docs. It requires some code to move the issues from the site into the issue, and then from the issue into the schedule app.

I imagine using a label for accepted proposals, which I would then use Sched's import API to grab those issues with the accepted label to create the schedule.

Once setup you wouldn't need me to do anything and would be seamless. The issues would just show up in github issues, maybe with a tag for "new proposal". Adding a tag for accepted would then update the schedule app.

Yeah, I would like to see what the Space Wranglers think about using github issues vs a google doc. If github issues is a learning curve for most of the Space Wranglers, it's probably not worth it.

[ScottDowne]

After talking to Bobby, he said having the proposals directly in the scheduling tool would be ideal.

Example, the user fills out the session proposal form directly on the website, hits submit, and it creates and unpublished session directly in sched. We then use sched to handle that going forward.

If we accept the proposal, we send them an invite to sched and they can become and moderator to their session and be able to update it.

[Saallen]

I will investigate @secretrobotron idea now on Sched.com
Looping @ryanpitts as he directed all srccon submissions to github from their festival website.
👋 @ryanpitts

[secretrobotron]

👍 from some experience with using the setup we've had in the past, we should try to get session info into the scheduling platform as soon as possible. Then, nobody has to deal with an intermediary format, or sign up for more than one service (e.g. github AND sched).

@ScottDowne found a delegation mechanism within sched yesterday that seemed really handy. As a wrangler, it's pretty useful to have proposals plopped right into sched (in a non-public state), where they can be accepted/rejected/edited/tagged, etc., and finally delegated to the actual session owner.

[ScottDowne]

Yeah, putting them directly in sched looks like the best option. It's easier to implement than github and about as easy to implement as google docs but gives us a way better interface to manage them from. On top of having them all in one spot.

@Saallen Question, do we know the fields we expect people to fill out when the propose a session?

[Saallen]

Yes we do- but I think before I confirm them I need to look at what the sched layout looks like on the backend as it would be smart to line the questions up to align with the sched layout.

[ScottDowne]

@Saallen ah, great. That's exactly what I was going to do and why I was asking.

[Saallen]

👍 We would like to use the exact questions from last year CFP as @thornet feels that they give a really good overview of the session and challenge the facilitator to think in an more collaborative and open way.
I am going to have a look now at the sched piece- would really welcome your feedback too. It would be great to make it align for a simple integration 😄

[secretrobotron]

Can you copy and paste here?
On May 12, 2015 10:59 AM, "Saallen" notifications@github.com wrote:

[image: 👍] We would like to use the exact questions from last year CFP
as @thornet https://github.com/thornet feels that they give a really
good overview of the session and challenge the facilitator to think in an
more collaborative and open way.
I am going to have a look now at the sched piece- would really welcome
your feedback too. It would be great to make it align for a simple
integration [image: 😄]

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[ScottDowne]

Here is a list of fields for Sched session creation: https://sched.org/api#session-add

Some are required, oddly start and end time are required. We'll need to fill in something fake and change it later.

There is a spot for custom fields, so we can get whatever we want from the user.

I think the only required things in that list that are a human readable things are name and type. The rest is either integration concern, or custom values.

[Saallen]

Moving your comment across to #32 @ScottDowne if thats ok with you?

[ScottDowne]

@Saallen Would be great :)

[ryanpitts]

Hi @Saallen! We used Screendoor to collect session proposals for SRCCON. It has a pretty decent form-builder, and you can embed the resulting form on your site to pipe data into the Screendoor system, where there are some decent tools for sorting, assessing, rating, etc. There are definitely quirks when using it collaboratively, but it's been an OK system for us.

Screendoor does have an API, though, so I wrote a small script that let us fetch new proposal data and publish it to the conference site via chat command in Slack. I didn't push the data into GitHub issues, though, although I suppose that would have been possible too. But the SRCCON site is Jekyll hosted on a gh-pages branch, so I was actually just creating JSON and programatically committing it to the repo, which had the great side effect of triggering a gh-pages rebuild automatically.

Maybe not a perfect alignment with what's being discussed here, but there are some pieces that might fit pretty well.

[Saallen]

Thanks @ryanpitts really helpful 👍