It should be possible to edit a submission's status after creation

[flyinggrizzly]

If a submission is waitlisted, it is likely it will later be accepted or rejected.

Currently, it is difficult, if not impossible, to edit existing submissions on the app.

It would useful to have this ability!

[nodunayo]

Haha, I kept on going back and forth on this. Part of why I didn't think editing (separate to deleting) was important is because I didn't have the 'waitlist' option previously, but we now do have that...

Now, editing a submission starts to make more sense, especially as one of my fears of a 'pending' option was that they stay in a 'pending' state. See here: #22.

Keep in mind: 'pending' is different to 'waitlisted'. A waitlisted proposal may eventually be 'accepted', i.e. delivered at the conference, but it's never really 'rejected'. It'll always remain as having been a 'backup'. However, 'pending', i.e. "I've submitted it and I'm awaiting an answer" will have to fall either way: 'accepted', or 'rejected', or 'waitlisted'.

Personally, I want to avoid a situation where we have a lot of 'pending' proposals on the website, because I worry about a lot of proposals that don't reveal any information as to what worked/didn't work and why.

Does that make sense? Again, #22 will elaborate on my fears.

Having said that, doesn't mean we can't have editing/deleting submissions on the site. I've been working with a designer friend on the website so once we decide what UX/feature makes sense here, I'll work with her to mock something up...

What do you think about the above and what Speakerline should/shouldn't offer?

(Also, I've got an upcoming big feature/issue I want to discuss with you re editing information on the site. Will post something about it soon.)

[flyinggrizzly]

Yea, reading 22 and thinking about it from the perspective of avoiding a pile up of abandoned entries, that definitely makese sense. So, I'd agree--no pending option, but the presence of a "Waitlisted" category strongly implies to users that they'll be able to update that result in the future.

And even if a "Waitlisted" entry gets 'abandoned', it still gives a better idea than having "Pending" submissions around, so I think editing would make sense here, and doesn't expose the app to the same danger of the pile of pending.

I don't know how far reaching the UX changes you're looking at are, but it's probably worth adding some clarifying microcopy to the submissions creation screen that helps people understand that submissions should only be added when at least a first decision has been reached (A, W, or R), otherwise you'll get very well-intentioned people adding entries after submission and misunderstanding the Waitlisted option as a catch-all for anything where at least some potential decision is still in the future (✋ I am guilty of this... the "Isle of Ruby" submission for Co(p|d)ing with depression)

And lmk when you want to talk new feature!

[nodunayo]

I don't know how far reaching the UX changes you're looking at are

We're all for small, incremental change, but also open to overhauling things/re-designs where it makes sense.

Explanatory text is a good idea! Will add a separate issue for that.

[nodunayo]

This has now been done and shipped!

Things that I'm working on:

• Working with a designer friend to improve the design of the 'edit' link
• A process for deleting speakers, proposals, and submissions:
  • I'm leaning towards a manual process that involves sending an email or opening a GitHub issue for now, whilst I figure out something better for the long-term.

Things I'm currently worried about:

• The Cucumber step definitions getting out of control:
  • Feature-coupled step definitions #37 is one of my top priorities before any new features
• A scalable way for information on Speakerline to grow and remain useful (i.e. minimal false and out-of-date information)

[flyinggrizzly]

If there's anything I can pick up, let me know what would be helpful!

I've been thinking about the problem of vetting changes as they come in, and it's definitely tricky. For requesting removals and things like that, at least as a short term we could set up a Google form that either just recorded in a spreadsheet, or even sent an email to someone. It's potentially a little more user friendly than just asking people to send an email (we could embed some javascript in the pages to present a link to the form, and scrape the page URL so form responses are tied directly to the page in question). It also doesn't involve building anything before we're ready.

For scalability, now that we have different years of an event linked directly together through the parent model, I want to say we should chart stuff. But I have no idea what. Number of submissions is easy but not necessarily useful. Is it worth making proposals taggable so you we can chart things like 'hard core technical' or 'community related' or whatever? (I would worry about how to handle language specific topics without tag-mageddon).

Regardless, lmk if there's anything it would be useful for me to do.

Also, should we start a Slack channel, or even email thread? It feels weird to be making this comment on an entirely unrelated issue...

[nodunayo]

Thanks for these thoughts!

Will start threads on the deletion stuff and also on helping maintain the integrity of our data soon.

Yes — I imagine we'll get to tagging eventually too, but staying away from that for now. Maybe, the earlier the better, whilst we have limited data, actually..? 🤔

Don't want to start a Slack channel or anything outside of GitHub just yet. Too much overhead for the current size of the project. And yes — I'm a big fun of us not building anything before we feel pain. I was aware as I was writing it that the comment above was typically misplaced, but it was really only for your benefit for now.