neinteractiveliterature
Add support for multiple users to collaborate on proposals
The user desire is to allow two users who are collaborating on a game to have access to see and edit a proposal in process. This would also support the situation where someone wants to hand off a proposal to a new person because they can no longer attend.
Nat says "It would probably be a good thing to add to the site, though - perhaps an even more general way to make a proposal “submitted by” multiple people (who would then automatically become the team members of the event once accepted)."
It occurs to me that providing a GM the option to preview a proposal with the view that is provided to the proposal committee would have alleviated the first situation that generated this request. I believe there is a different request for that type of feature already submitted.
This feature request continues to be important -- we had a game delayed past first reveal because the proposing GM didn't have cope and the other two GMs couldn't see or edit the proposal. There's no particular reason you shouldn't be able to add GMs/proposers to an in-progress proposal and several reasons to be able t do this; after all, co-gms can edit a game after it's live, why not before?
Hey Josh. I agree this would be a great feature to have, but it's surprisingly heavy to implement given the current data models. Event proposals and events are two entirely separate database tables, which means we're basically doing two entirely separate implementations of models, APIs, UI components, etc for "this thing has team members." Granted, these could possibly share some code, but the UIs are different enough that it's not clear how much of it they could really share.
Additionally, there are some non-obvious security ramifications here. Specifically, I'm thinking here of the UI element that allows GMs to choose a person to add, which currently allows GMs to search the list of registered attendees of the con. We've considered this acceptable in the past because GMs have some level of trust by virtue of running an event at the con. But, allowing them to do this before having had an event accepted essentially means that anyone in the world can search the attendee list (by starting a proposal and adding folks before filling it out fully, or much more simply via direct API usage). This is almost definitely a non-starter for us, thus we'd need some alternate way to do invitations, which means building a set of features for that.
You get the idea. None of this is insurmountable, but it's a bunch of weird little corner cases that all take effort to solve. It's all doable, but the question becomes where do we prioritize this versus other important features, particularly those requested by the con chair and other staff.
Finally, I do want to mention that writing a comment like the one you did is maybe not the best approach to getting us to prioritize a feature. I do appreciate that it's causing real issues and that that's super frustrating, but "why couldn't you just" is hard to hear from my point of view. Sorry to be touchy around this, but hopefully what I'm saying makes sense and helps explain why we haven't done this yet.
I was requested to leave a comment so I did. I was somewhat surprised that this ticket has been around for 2 years, but as you say, there's limited time on a volunteer project and plenty of other things to prioritize.
Good point about the permission issues. I think it would be better to trust GMs less -- as a GM I would be perfectly happy having an invite system that required me to use an email address to invite someone in as a GM and them to accept before they were added to my game, and that kind of interface would work well for proposals as well as for accepted games. I have been in the past surprised that when added/adding someone they'd automatically be part of the game, but then had to join it manually to do some things, and this could be an opportunity to clean up that workflow.
Were I designing it from scratch (I am not) or working on it as a coder (likewise) I'd probably have proposals and games in the same table. They share 90% of the same data, and a type field could be used to segment off things associated to games that are inapprorpirate to as-yet-unaccepted proposals. That said, that kind of refactor is both dangerous and pervasive, so I an understand a reluctance (at the least) to do such a thing.