Update plugin name

[jennybeaumont]

Changing the name from WordCamp Talks to WordCamp Talk Proposals.

• Root url
• Singular name
• Plural name
• Page title
• Admin menu item

[iandunn]

I wonder if it'd be better to use "session" instead of "talk", to be consistent with the existing language on wordcamp.org?

Something like "WordCamp Call for Speakers" might also be good to consider, since that's a common term.

Once the plugin switches to use the existing wcb_session post type, though, will it even make sense to be a separate plugin, or should it be integrated into wc-post-types as a new module? It seems like we'd want the UIs to be integrated, at the very least.

I'm still picturing separate screens/workflows for rating proposals and managing accepted sessions, but both screens would be under the Sessions menu, for instance. So maybe it'd look like:

• Sessions
  • Accepted Sessions
  • Rate Proposals
  • Tracks
  • Settings

[tomjn]

In isolation I like this, but that would give us 2 menu entries named sessions in WordCamp sites, a talk and a session aren't the same thing and we spent some time discussing it in meetings, a session has a time please and length, whereas a talk does not.

Merging the two complicates things and introduces new problems, e.g. what if 2 speakers want to swap slots? Or if a talks are swapped around, creating a scheduling clash that needs fixing. With 2 post types this would be a drop down in a session post to pick which talk goes in that slot. It also complicates imports and exports, which now contain timing information

I'm also keen on the idea that this plugin could be used outside of WordCamp.org. Tightly coupling it this way would limit the scope of potential maintainers unnecessarily

[iandunn]

that would give us 2 menu entries named sessions in WordCamp sites

I'm not sure I see the problem. Do you think that organizers would be confused by "Accepted Sessions" and "Rate Proposals" under a single "Sessions" menu, and not know which is which?

a talk and a session aren't the same thing

I disagree. I also thought that we'd already agreed to integrate with the existing wcb_session post type.

what if 2 speakers want to swap slots

I don't see the problem; the existing session post type has a metabox for the session date/time, so if an organizer wanted to switch speakers around, they'd just update the times on both posts.

It seems tedious to have to manually create each slot then assign someone to it.

in the past people have talked about creating a drag-and-drop tool to build a schedule visually, and it'd update the existing meta data on each wcb_session. That seems like a better improvement on the existing UX to me than having to create separate slots.

It also complicates imports and exports, which now contain timing information

Can you explain that more? The problem isn't obvious to me. I also don't see import/export being an important feature for WordCamp organizers.

I'm also keen on the idea that this plugin could be used outside of WordCamp.org. Tightly coupling it this way would limit the scope of potential maintainers unnecessarily

I think for something like this, a generic plugin has more cons than pros. It's not going to integrate well with our existing code and UI; it'll become bloated with features we don't want, because somebody else with a different use case wants them; it could introduce incompatibilities with our other code; it'll be harder to add new things we want because we'll have to think about how it'll affect others running the code, and we'll also have to deal with backwards compatibility.

[iandunn]

It seems like we're still really far apart in our visions for the project's concepts, UI, UX, code, etc, at a fundamental level.

I'm worried that the entire way we've been going about this process has been hurting us more than it's helped us. Right now we're trying to build a very large plugin with a lot of features, and merge it all at once into an existing system. And we're also spending a lot of time writing code that we don't agree should even be used, and then discussing it after the time has already been spent.

I wonder if a more Agile approach would be helpful here. Something like this:

1) Start with the existing wc-post-types plugin, and identify a small (but useful) iteration we can make to improve it. For example, custom post statuses for proposed, declined, pending, and accepted sessions. 2) Discuss that feature and come to a consensus on what it should look like, including quick-and-dirty wireframes for any UI. I think the wireframes are essential for something like this, because it's so easy to miscommunicate when relying only on words. Creating wireframes forces us all to think about the details, and that often points out problems that otherwise would be missed until after something is built. 3) Build the small iteration as a patch for the existing wc-post-types plugin. The wordcamp-talks code that's already been written could be extracted out and reused in many cases. 4) Merge the small iteration into wc-post-types

Then, we'd go back and repeat the steps for the next small iteration (like the front-end form to allow speakers to submit proposed sessions, and then again for allowing admins to rate the proposed sessions, etc.

I'm open to other ideas, too. Maybe something Agile-like isn't the best approach because we already have so much code written? It seems like we need to do something different, though, because the current approach doesn't seem to be getting us all on the same page.

@jennybeaumont, @tomjn, @imath, @andreamiddleton

[iandunn]

I think it'd also be helpful to have a designer giving input in all the discussions/decisions, since that's not a strong suit for most developers (especially me).

[imath]

Thanks for your comments and contributions. imho, we have 3 different visions of what should be a tool to manage WordCamp Talks :)

Ian invested a lot of time on a plugin previously done with the wcb_session post type. If i remember what i saw in meta trac, each submitted form was converted into a draft post type. I don't know if this tool is already available to manage submissions on WordCamp sites, or if it's a project you've been working on.

I have made some work to rename and improve some features, and Tom has also improved a lot of things (many thanks for this). So it's a bit too bad to go back imho. But if it's the best way, then i'm fine with it.

I think what matter most is users, not designers or developers. If users are satisfied with what exists, then there's no reason to change :)

If this plugin is here, that's because WordCamp Paris organisers saved time to select the Talks, and speakers saved time to submit their talk (especially the one who were submitting more than one talk). So Jenny and i thought it was just a question of adaptations so that it can also be useful for other WordCamp organisers.

I suggest we all take some time off the project to think calmly about the best road, maybe we've tried to go too quick with it.

Any decision with it will be ok with me.

[tomjn]

I think some confusion has happened, my understanding was that we agreed accepted talks and proposed talks should not be 2 separate CPT's, not that sessions and talks should be merged. I take this purely from a data structure standpoint.

My understanding that the reason using separate CPT's for accepted talks and submitted/pending talks was because it was difficult to view one or the other in the plugin at the time. This is why I begun work on the post_status branch, with the aim of removing metaboxes and code and bringing standard post status mechanics and workflows that would be easier to work with in the future.

This is data structure though, UI/UX/Workflow/Process are built on top and don't have to be exact replicas of the underlying data. Nor does anything I've proposed prevent drag and drop interfaces.

In an ideal world we'd have a talks menu, and a schedule menu. With the schedule menu replacing what we currently have as sessions. Opening it up would give you a calendar you can drag talks as well as predefined blocks such as break. But that's UI code, at which point the blocks might represent comments, and the slots might be defined by pixels in a photo of Whoopi Goldberg. The point being that the storage and data underneath is encapsulated, and the result is the same.

So I don't think it's good to use UI to decide data structure, or vice versa.

My current standpoint on what needs doing next is that:

• Cleanup to remove the workflow metabox and private status system is needed - I've begun this and it's mostly complete
• Simplifying things down to standard data structures without the relevant UI steps taken currently in the process, and the numerous options that the plugin currently has
• Finally, once those steps are taken and the plugin is slimmed down, it will be usable as is, and a final UX can be designed
• We are not at the stage that wireframes and UX can be designed. The plugins functionality already fulfils the necessary requirements though

Regarding the UI proposal of:

• Sessions
  • Accepted Sessions
  • Rate Proposals
  • Tracks
  • Settings

I don't see how this is relevant to the 2 CPT's as it's a UI proposal. There's nothing preventing us from creating a custom UI menu structure such that:

• Sessions lists accepted sessions
  • Accepted Sessions a standard post listing filtered to those talks that have the status publish
  • Rate Proposals as above but for everything that isn't publish
  • Tracks a drag and drop builder for session post types
  • Settings a settings page

The assumption in the meetings thus far and the past usage has also been that ratings and selection has occurred on the frontend.

I'm happy to entertain UI ideas such as this, there's a lot of scope, but data structure != workflow and UI, and it's dangerous to conflate the two

[iandunn]

I totally agree that data structure != UI/workflow/etc, but I think that "talks" and "sessions" are the same thing, and that it makes sense to use the wcb_session post type for proposed sessions/talks, declined sessions/talks, pending sessions/talks and accepted sessions/talks, for all of the same reasons that it makes sense to have a single "talks" post type instead of two "talks" post types -- the data is fundamentally the same, the posts just have a different status.

I think using the front-end for admin tasks is the wrong approach, because it's counter-intuitive, inconsistent, and makes an admin switch back and forth between the front-end and wp-admin.

My overarching leeriness is because this doesn't feel like a consistent integration, but more like something tacked-on with very different design and development approaches than the rest of WordCamp.org, and I'm worried about the kinds of unforeseeable maintenance burdens that will come up over the next ~5 years.

Having said all that, though, I've been thinking about the whole thing more, and I do agree that it is too late to change all that now. I think we should continue moving forward with things they way they are (separate "talks" post type, front-end admin workflow, etc). It'll still be helpful to remove the unnecessary features in order to make the review more manageable, and to make the plugin closely match the needs of WordCamp organizers, but those features can always be maintained in a separate fork if you want to use this plugin beyond wordcamp.org.

We can talk about it more at the meeting today.

[jennybeaumont]

So, I'm just getting caught up on this conversation, and there does seem to be a bit of confusion, as well as competing views on workflow and UI.

Some of the confusion can be cleared up, I think, with a quick reminder that the purpose of this issue was to update the plugin name from Talks to Talk Proposals. Why is this important? Because when you say "talks" and "sessions" are that same, that rings true. But when you say "proposals" and "sessions" are the same, we better understand that they are not.

We DO agree that they are now to be based on the same post type.

We had consider WC Call for Speakers and simply thought it a bit long. But I quite like it.

We are also coming from different places and merging in the middle, and quite frankly, I think we're doing a pretty good job of it considering the time we have to put in, working asynch, etc. Starting from scratch was something we had considered and rejected because WE ARE SO CLOSE to a nice working plugin that we can and get feedback on.

The open question I extract from the above is around the menu item - to keep them separate or to merge. I personally still like the idea of them remaining separate for now, for this milestone, but am very open to the idea of that changing if the user feedback suggests it would be better UX.

I do think pulling some design eyes in would be a good idea for the front-end, (esp touching up login, etc), but I don't see an immediate need in the admin. Let's circle back to that once we're happy with basic functionality and code base.

[tomjn]

We DO agree that they are now to be based on the same post type.

My understanding was the reverse, proposals != sessions therefore proposals and sessions are 2 not 1 post type. I think it's important we name the post types when we mention them as historically there could have been 3 not 2 post types, and there are multiple post type merging discussions ongoing that reference different things

So to clarify:

WC Talks

• Has 1 post type ( A )
• Some of us discussed splitting it into 2 ( A, and B )
• We decided it should stay as 1 post type ( A )

WordCamp Sessions

• An existing plugin on WordCamp.org that has 1 post type ( C )
• It was suggested that Talks and Sessions are the same, and the WC Talks plugin shouldn't use A, and only use C

This lead to the following proposals:

• replace A with A & B - rejected
• replace A with C - rejected

Throw in lots of people muddling up the above two as C&B, A&B vs C, or confusing the ordering of things.

Conclusion:

• WordCamp Talks has a single post type, some people think it should be called Talk proposals not Talks
• WordCamp Sessions is a different plugin that has a different post type that serves a similar but fundamentally different purpose
• The two are separate and won't be merged

[jennybeaumont]

Wow, communication is challenging indeed. This is not my understanding at all. My understanding is the following:

• WC Talk Proposals has/d 1 post type
• WC Sessions has 1 post type
• It was decided that the plugin name would change from WC Talks to WC Talk Proposals for clarity (this is independent of the post type)
• We initially thought we would retain the separate post type for WC Talk Proposals
• We then decided to adopt the post type used by Sessions for Talk Proposals
• The current discussion hinders around UI, and whether or not, despite them using the same post type, if they should still be separate menu items.
• There is also discussion as to whether or not these should be two separate plugins or merged into one single plugin (I'm for the former).

I also would like to reiterate that this issue — the name change — concerned only the plugin name and menu item, not the post type.

[tomjn]

Ah, I'm not a fan of that approach, all the arguments for consolidating on the sessions post type are UI/UX oriented, and fundamentally a proposal != a session. It also tightly couples us to the WordCamp.org site on a data level, preventing use of the plugin outside of WC.org, and makes testing difficult. Right now we can fire up any local WP environment, but this would isolate testing to the meta Vagrant fork which very few are familiar with. Sidestepping that would involve an abstraction layer that registers a post type anyway, providing us with no benefit and technical debt.

The only benefit I see is that everything session related will appear underneath the sessions menu item in WP Admin by default, which is a UI/UX thing. We can change it to do that even with a separate post type so I see that point as moot

WC Talks should be a clean module that contains itself that tries to implement call for papers, not a mish mash of CFP and schedule wrangling, and UI/UX should not dictate the basic data layer

[jennybeaumont]

Ah, I'm not a fan of that approach

Which are you referring to? Merging into one plugin? If so, I concur. If we're back to the post type debate, then I'm confused.

[jennybeaumont]

Also, I'd suggest bringing general discussion back to slack, this issue is becoming quite the tangle :)

[tomjn]

We discussed in slack, this issue is circling back to the original goal of renaming talks to proposals