Simplify proposal models?

[martey]

Right now, there is no real difference between TalkProposal and TutorialProposal objects other than their verbose_name.

If I submitted a pull request to subsume them into the currently abstract Proposal model, would it be accepted?

[codersquid]

Based on what @paltman said, it would make sense to look at the submission models in https://github.com/pinax/pinax-submissions

[ossanna16]

Has this issue been resolved, meaning can I close this PR?

[martey]

This project still has TalkProposal and TutorialProposal objects, so this is still an issue.

Right now, if you use this example project to create a Symposion site, you will run into issues if you try to convert a talk into a tutorial (or vice versa).

It is still not clear whether it would be useful to make the Proposal model concrete now, or whether any changes should wait for the work to use pinax-submissions to be merged into Symposion master.

[ossanna16]

@martey Thanks for your reply! Excuse my ignorance but what exactly is the issue with having these two objects? Looking at this from a non-technical point of view but the point of view of someone who was submitted quite a few talk proposals in the past and has reviewed talks and tutorials for conferences, it does make sense to me that there would be these two objects. Also I might be wrong but I don't think it happens often that people convert a talk into a tutorial or vice versa. Usually what people will do is change the time slot of a talk, maybe they decide they want to give a 30 instead of a 45 minute talk, which as far as I know isn't an issue with symposion but I have personally never seen someone change a talk to a tutorial and vice versa since these are two completely different things so I wonder if this case is too specific for it to be merged into symposion core. So if you could clarify things that would be wonderful 😊

[mjumbewu]

@martey Also, the current model makes sense to me from a technical standpoint. I have a conference that I'm trying to use Symposion for that has 3 types of submissions: talks/papers, workshops, and posters, each of which have different fields that I want to collect. For this use case, it's convenient to be able to create models with different fields and just have Symposion know what to do with them.

Even though the Talk and Tutorial models are identical in the current template, it's a nice hint at what you can do (i.e., create diverse proposal types). Maybe the thing to do would be to give TalkProposal or TutorialProposal an additional field or two to explicitly demonstrate this capability.

In your case, since talks and tutorials will end up being similar, maybe the thing to do is have a single ConferenceProposal model that has a proposal_type attribute or something where you can choose from "Talk" or "Tutorial". That would make it possible to switch the types.

[martey]

I have personally never seen someone change a talk to a tutorial and vice versa since these are two completely different things so I wonder if this case is too specific for it to be merged into symposion core.

While new to symposion, I was working on a conference site that was created using this project as the initial template. Because the default Talk and Tutorial models had the same fields and use the same templates, a talk was accidentally submitted as a tutorial. If the site had been organized to better differentiate between talks and tutorials, this probably wouldn't have happened.

Even though the Talk and Tutorial models are identical in the current template, it's a nice hint at what you can do (i.e., create diverse proposal types). Maybe the thing to do would be to give TalkProposal or TutorialProposal an additional field or two to explicitly demonstrate this capability.

I think if this is "a starter project demonstrating a minimal symposion instance", having a single Proposal or ConferenceProposal model would be better than two identical (or almost identical) proposal types. I think having an explicit link in the "Usage" section to the documentation explaining how to customize proposal types would be more instructive (and should be added regardless of whether the proposal models are changed).

To be clear, I don't think anything needs to change in symposion core, but I do think that consolidating the proposal types in this starter project would make it more useful.

[ossanna16]

I tend to agree with @mjumbewu. Adding additional fields to demonstrate the ability of the two models sounds like a great idea to me.

@martey I'm +1 on documenting how to customize proposal types, however I still believe that your suggestion of creating one proposal model isn't feasible even for the symposion starter project. The use case you mentioned still seems too unique to be applicable to a wider user audience and creating only one model could also be confusing to people.

I think it would be great to keep discussing this in our #symposion channel of our Pinax Slack team so that more people can chime in. If you'd like to you can sign up here http://slack.pinaxproject.com. Thank you!