jnf / blinder Goto Github PK

on front page:
The confirmation contains a unique, private editing url for your proposal => URL

Here's the list of pages for which we need copy for SCRC 2014:

• RFP Info & Process page (before a person completes the new proposal form).
• Blind infos (short paragraphs below each blind title that describe why we want this info).
• Thank-you page, post-form submission that includes timeline and next steps.

Google analytics? New Relic? Whatevs. We should be tracking trends/usage.

The title of my email says: "Your proposal for Steel City Ruby 2014 RFP". The confirmation page says something similar. Two objections:

1. elsewhere we call it CFP. Could we standardize on one? I slightly prefer CFP.
2. I think it should be "Your proposal for the Steel City Ruby 2014 CFP", with a 'the'.

Blinder should:

• Email me and Seejee when a new Proposal is created.
• Email proposal submitters a confirmation that their proposal has been received.

The mailing list is finalizing language for the latter.

It'd be handy to leverage the Notes functionality for admins reviewing proposals for safety.

Create a notes table in the db that lets review users record text notes while reviewing a submitted proposal. Create CRUD workflow for notes.

Notes are private; no reviewer can see any other user's notes.

We just marked a large set of proposals as safe for review. However, depending on we how handle the "Balancing Info" section, many of the proposals may not be safe for review at the next blind level if we have to scrub them of previous talk titles and links.

Perhaps we should have a many-to-many between proposals and blind levels so that we can say whether or not a proposal if safe for review at each blind level.

Chances are we'll need to tweak the css once copy and structure are finalized. This is just a reminder to check it out.

I've already had an email exchange with a submitter about formatting. I've already added Markdown support to the app in general, so I just need to add output formatting to the thanks view/email and the proposal review pages. I'll also add a note to the proposal form that Markdown is accepted.

I noticed this comment you made on another issue, Jeremy:

If we wanted to keep the question abstraction really high (and I kinda do, but mostly because it's fun), we could look at marking some Questions with a new identifier (Sortables? Listables?) that tags them for display on management/review screens so I can easily grab them (and use them for hooks for sorting/display options). What do you think?

And that's exactly what I'm reaching for now :) Since we'd like to review by tech/nontech/hybrid, it would be super useful to have that field on the review page and be able to sort by that. I'm going to take a poke at this.

I'm a uncomfortable with the Personal & Contact Information section. The introduction paragraph can be read as saying that this whole section is private "... never share ..." yet we ask for name and bio, which we surely intend to publish. What is left ambiguous is what else are we planning to publish. I suspect we intend to publish Twitter handles, but that is "contact information" which we just promised to never share.

We need a very bright line between what we want to publish for an accepted talk and what we will keep private. (From my insider view, I'm assuming we won't publish phone number, email address or T-Shirt sizing info. (We don't say we won't publish T-Shirt sizing info.)

Can we add never published to each entry box for information that we will not publish?

Or maybe edit just the text to be cleared.

just to make it easier to read

The text should mention the length of the talks we expect

I proposed having people send you the slugs of the talks they like so that you can sort | uniq -c | sort -n -r -f 2 as the simplest voting that could possibly work.

People said they wanted to be able to vote in blinderapp, and I agree that for the long term general solution, that would be ideal.

But for now, I'm imagining a little bit of JS to make the collection of slugs for emailing a bit less tedious and error prone--

• Have a checkbox next to each talk on the review page.
• Have a textarea at the bottom of the review page.
• When you tick the checkbox, JS grabs the slug for that proposal and appends it to the textarea's value, one slug per line.
• Unticking the checkbox removes the slug from the textarea's value.
• When you're done ticking boxes, copy the textarea's value into an email and send.

Bonus features:

• A clear all button that would uncheck all boxes and clear the textarea
• Display the count of ticked boxes on the page, so that if you're allowed to vote for 10 you know when you've reached that

Wdyt?

This repo is public, and it's used by conferences which focus on open technologies, but it's not easy to find out how I'm allowed to use or share the code. Could you add a LICENSE file to make it easier for users to understand how you'd like it to be used?

http://choosealicense.com/ might be helpful here.

Thanks!

All the radio buttons have the same name, so when the validation fires you always get 2 of 3 of the radio buttons are missing

Once all the auth is in place and the review routes are reactivated, we'll need new/extended specs to describe and test the blinded review aspects of the application.

http://cfp.steelcityruby.org/1/new

What does '1' mean?

Looking at the routes, then, I see that that number is the event_id.

Could events get a slug and use that slug instead of a number?

http://cfp.steelcityruby.org/scrc2014/new

or

http://cfp.steelcityruby.org/2014/new

Much better.

Little thing.

Maybe we should allow Markdown? Or maybe nothing at all.

Here were my experiences with using HTML and JS:
I did something awful to it at about 8:07 this morning when I pasted the source of the page into one of the other boxes. So it can be broken. What happened when I did that and submitted is that I got back a page that said 'data:,' in the URL and had no source. Pressing back and removing the source of the page fixed my issue - I was then able to submit. It kept my text when I pressed 'back' but lost my radio button settings.

When I submitted for real, my HTML in the title got interpreted, including my unclosed tag, on the confirmation page. My unclosed tag was sort of fixed in the email I got sent - it only affected the rest of the title, not the entirety of the email. I will attempt with JS next. - JS also gets interpreted.

As a conference organizer, I've wanted to have various pieces of data in various spreadsheets at various times.

When we are discussing final talk selection, I want:

• Speaker name
• Talk title
• Link to the whole proposal
• Maybe another custom field or two (ex: talk length)

When I am sending out acceptance notification emails, I want:

• Speaker name
• Talk title
• Email address

When I am working on the website, I want:

• Speaker name
• Talk title
• Abstract
• Bio
• Twitter handle
• Website
• Avatar

When I am ordering t-shirts, I want:

• Speaker name
• T-shirt cut
• T-shirt size

So I guess an export of all the data in CSV would work, since I could then just delete/hide columns I wasn't interested in... bonus points though for an export screen that shows all the questions with ticky boxes then generates a CSV with just the answers for those questions in it.

Right now my workaround is to rails c and poke around until i find the question IDs of the info i want, then make a query with that, and lots of .join(',').

Just wanted to write this down so I didn't forget... Hopefully I'll work on this before the next time I'm frantically using blinder with self-imposed, looming deadlines ;)

Different than #23, although newrelic has errors, we should at the very least make sure submissions aren't throwing errors or something, with airbrake or bugsnag or whatever the cool kids are using these days.

I volunteer to do this before tomorrow unless there are more pressing things I can be doing to help.

Eh, I didn't think it would bother me, but a I've got a couple of testing proposals in the mix. Now that we're past testing and into mvp usage, let's add a way to destroy those testing proposals.

All proposals, regardless of event, will have some set of basic fields. Things like talk title, abstract, and speaker contact info might be best treated as special cases so they can fetched and displayed easily.

For example, as Jeremy has already pointed out, finding the email address for a proposal is not easy and is somewhat brittle.

this will allow for a follow up message and includes instructions for those who have missed or need directed to what will happen now that submissions are closed

Seriously. I'm adding helpers with a rapidity that will quickly reach critical mass without intervention.

Upon initial seed I receive an error about a role not being present

FATAL:  role "blinder" does not exist
/Users/cmlucian/projects/blinder/db/schema.rb:17:in `block in <top (required)>'
/Users/cmlucian/projects/blinder/db/schema.rb:14:in `<top (required)>'
Tasks: TOP => db:schema:load

Heartbleed. :/

Add a method for admins (who see full proposals, but have abstained from the selection process) to mark a submitted proposal as ready/ok to review. Submitted proposals are unsafe by default, and are not accessible to reviewers until marked safe.

This give admins the opportunity to address potential issues (identifying information, incomplete submissions, etc.) with proposal authors before any member of the reviewing team sees the proposal.

It'd be nice to at least do a 760px view for most tablets. Not sure we need to optimize down to phone levels, though.

Labels for radios on the form have a font-weight of 300. It makes them look out of place:

Either this font-weight should go away, or everything else gets a base of 300. Messing around with it a little in inspector, I kinda like the latter.

Thoughts?

Justin requested this as he'd be on an airplane without access. He and I worked out a decent-ish way to dump blind-appropriate Proposal data to a text file. Thinking I should clean it up a bit and make it a rake task.

For reference:

x = Proposal
  .where(safe_for_review: true)
  .collect { |p| [p.responses.reject { |r| r.question.blind.level > 1 }
  .collect { |r| [r.question.label, r.value].join(': ')}, p.slug + "\r\n" + '-' * 80 + "\r\n" * 4]}
  .join("\r\n\r\n")

Whatever time we choose as a cutoff point, we should stop accepting submissions and edits-- refuse CollectController#creates/updates, redirect the edit links to go to show, and have a "sorry, we're closed!" action or something.

For short term fixes, we could have someone manually deploy a change or turn off the dynos or something at that time.

A neater, more sustainable fix would be to have a datetime setting on the event and make that change automatically.

This is a form on the internet... so I predict it'll be like, 4 hours after tweetings til we start getting spam :(

Ask people to type 'SCRC' into a text field and reject with a human readable error message if it's not that?

This can wait til after we open, buuuuut i waaaarrrned yooou

Reseeding the db every time we change this content is painful.

Slugs should be memorable and easy to pronounce. Zoo Pass is an interesting example of a more human readable phrase generator.

For IE 8, there appears to be rendering issues. Have not confirmed this on multiple machines (yet).

I want to make a wiki page for GitHub OAuth config

Let's not use save!. Leverage railsy stuff and show friendly errors (mostly missing required fields) to people trying to submit proposals.

Add a mailing list for CFP reviewers. Whenever an admin marks a proposal as safe for review, email out the proposal to the review mailing list.