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
Google Forms API harvester #75
Comments
From my email to the working group. Here is a working model for using Google Forms for speaker / presentation submissions. What I've thrown together: Hurdle 1, editing form responses FYI - Same thing happens for the presentation form. Hurdle 2, connecting speakers and presentations. Hurdle's not solved:
Both of these hurdle's are solvable. I just didn't want to make a complete system if we decide to do a different direction. Anyway, this should at least give you a working model to share with the other committees, and get feedback on if using google apps will work. Additionally, if you want mess around with your own setups, here are the docs. |
Possibly use tabletop.js to harvest. |
Thanks to @cdmo for finding Multiple options available. |
Fruitful beginnings @ http://roastduckalamode.github.io/fromSheetsToJekyll/ |
This is awesome. 💯 |
slow 👏 |
I think this approach is problematic for a person submitting a talk proposal (or, more importantly to me, a preconference workshop proposal). I don't think we should make those people fill out two different forms. I'd like to see the required data be generated from a single form that includes both talk / workshop info and contact info. We plan to put out our call for preconference proposals this week. Our committee lead is starting to work on a google form. Please let me know who she should talk to in order to make sure the form will work for both submitters and the website group!! It may be moot if workshop presenters won't be included on the 'speakers' list. Let me know. Thanks! |
@HackMasterA The only problem with using a single form for submissions is that if there are any fields associated with the speaker, and they are submitting more than one talk, they will have to enter the same data multiple times. And then if there's a typo, they will have to edit it in all of them. Perhaps there are not enough multiple submitters to matter here? We are collecting more data than we normally do with regard to speakers. Normally, it's Name, Email, and Org. But twitter handles, bios, etc can come in handy and follow other conference conventions. If you still want a single form after this explanation, let us know. |
@HackMasterA @sdellis Do we need to collect all of that data when the propose a talk? We'd be gathering info on lots of people whose info we won't need. Why not just send out a google form to the people who's talks / sessions have been selected when that time comes? |
@bibliotechy++ |
+1 was going to ask the same question; great solution! |
@bibliotechy 's plan looks fine to me. the person working on the form for proposals can contact me if they have any questions. The only feature they should include is the script that generates an automatic "edit response" url |
I understand what you are attempting to do here, but there's something about the workflow that's bothersome to me. I think it's the timeline, 1) submit a proposal, 2) several months later submit a bio and link it to a proposal? Yeah, I'm not feeling this... A point was made that the traditional procedure amounts to collecting biographical info about people who will not end up being part of the program, but I don't necessarily see that as a problem. It just seems cleaner to 1) create a profile, 2) submit a proposal. As far as multiple submissions go, can we not treat these as edge cases and configure them manually? |
@dlacy I think the workflow is:
Does that help clarify? However, have bios been included on the proposals during the voting process? If so, might as well get everything in one swoop. |
@roastduckalamode Thank you for the clarification, and I understand completely the desire to have this data controlled dynamically through google sheets. So is this workflow solely intended to spare the user from filling out 2 different forms in a row? What if the submission instructions were written as a series of steps: Step 1: Create a profile Sorry to muddy the waters, I just don't like the idea of collecting bios down the road. |
@dlacy @roastduckalamode Seems like if the profile form exists, people could either fill it out at submission time or at acceptance time. Do we need a central "submit a proposal" page on the site with links to these various google forms? |
@dlacy @HackMasterA I'm fine with that approach. If you provide the links to the forms you want to use, I'll create a page on the website that outlines that workflow and links to them. Additionally, if you look at the second page of these docs, you could have the email input from step 2 as a select list, populated with email addresses from step 1 (or names, for privacy's sake). I can help out with that if you need. But again, not necessary. A regular old text field will work. Even if there is a typo in the email address, we can fix manually. |
Cool. I'd vote against the drop-down, since that makes things less flexible. |
@roastduckalamode I assume, from the info you are collecting on the speaker form, that everything except the email address will be published on the site. Can you confirm or correct me? |
There hasn't been an official discussion about what information to collect about speakers. At minimum, name and short bio. I think pictures would be nice. But the picture would need to be hosted elsewhere. Institutional Affiliation makes sense as well. If they leave anything blank, it won't show up. @sdellis, what do you think? |
Create some form of parser to harvest presentation / presenter submissions
The text was updated successfully, but these errors were encountered: