-
Notifications
You must be signed in to change notification settings - Fork 154
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
Proposal: Multiple speakers in submission #311
Comments
Hello @Schwad. I am a developer that worked on a recently added feature that generates conference websites using the CFP schedule and sponsor data. I don't know very much about the main proposal part of the app but I see that when a proposal gets accepted and then finalized it becomes a program session and it is then possible for an organizer of the event to add speakers to the session from the backend. Forgive me if you already knew all that. I could see how being able to submit a joint proposal would be a useful feature. I can imagine there might be complications around dealing with the associations between users and speakers and the correspondence, approval and proposal confirmation process with multiple users/speakers. It seems that the added speakers to program sessions are not associated to users so perhaps it would be simplest to use some version of your I will say that we added some nested forms with the new Website feature and used a simple Stimulus Controller using the pattern that Chris Oliver suggests in a GoRails Video. It works great and you can see how we wired it up for adding multiple fonts. Thanks for your interest in contributing to cfp-app and hopefully you will get further responses from the Ruby Central core team in the coming days. |
Thank you for the additional context on this @jonsgreen. That makes sense now why the back-end already supports multiple speakers. I can appreciate why this might be slightly tricky to implement and look forward to further feedback. I think it would be nice to indicate copresenters earlier so that organizers can determine if they want to support that format |
Background
I would have submitted this as a PR but first I want to run this by the maintainers as an issue, and if we can get agreement I am happy to take this on myself.
@paracycle and I were submitting a joint talk to a conference using this app but there was no clear way to indicate a second presenter. So I had to hack that information in. I think this is something that ought to be supported
Proposed solution
The backend already supports multiple speakers per proposal. But even developing locally I was unable to find a clear way to do this from admin.
I think not every conference would want to allow this, but perhaps there can be a boolean admin event setting for
allow_copresenters?
; and from there we have two possible ways I could see this be implemented:Stripped information
We have one "main" speaker, but there are additional fields for copresenter emails. These are not stored as full fledged speaker objects but rather as an array of "copresenters" on the
proposal
object.Full speakers
Use something like cocoon to allow the user to add
n
copresenters with all the first-level information of the main speaker.For reviewers
Am I completely missing an obvious feature here that makes this issue moot? I think the admin could create custom fields for this but copresenting is relatively common so I reckon it should be a first class feature even as an option.
The text was updated successfully, but these errors were encountered: