jnf / blinder Goto Github PK
View Code? Open in Web Editor NEWWe use Blinder to collect and review responses to event RFPs.
License: MIT License
We use Blinder to collect and review responses to event RFPs.
License: MIT License
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.
Here's the list of pages for which we need copy for SCRC 2014:
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?
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
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.
Heartbleed. :/
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 title of my email says: "Your proposal for Steel City Ruby 2014 RFP". The confirmation page says something similar. Two objections:
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.
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!
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--
Bonus features:
Wdyt?
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.
Chances are we'll need to tweak the css once copy and structure are finalized. This is just a reminder to check it out.
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.
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.
Blinder should:
The mailing list is finalizing language for the latter.
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:
When I am sending out acceptance notification emails, I want:
When I am working on the website, I want:
When I am ordering t-shirts, I want:
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 ;)
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
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.
The text should mention the length of the talks we expect
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")
Seriously. I'm adding helpers with a rapidity that will quickly reach critical mass without intervention.
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
Google analytics? New Relic? Whatevs. We should be tracking trends/usage.
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.
Slugs should be memorable and easy to pronounce. Zoo Pass is an interesting example of a more human readable phrase generator.
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.
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
I want to make a wiki page for GitHub OAuth config
It'd be handy to leverage the Notes functionality for admins reviewing proposals for safety.
Reseeding the db every time we change this content is painful.
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.
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.
on front page:
The confirmation contains a unique, private editing url for your proposal => URL
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.
Let's not use save!
. Leverage railsy stuff and show friendly errors (mostly missing required fields) to people trying to submit 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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.