Making Vestibule easier to reuse at other community events

[fidothe]

I used Vestibule for UIKonf's CfP earlier this year, and I'm going to do it again. I thought it was worth opening an issue to talk about how (if at all) I can help make Vestibule easier to use at other conferences so that more people can benefit from this lovely little app, and so that it's easier to contribute changes and improvements back.

My biggest pain points were:

• Hardcoded mentions of Ruby Manor all over the place
• Needing to use some, but not all, of the features -- we had community voting, but decided on which of the top-ranked proposals we'd take (there were issues of duplicate topics, multiple proposals from speakers, that sort of thing).

Would you be receptive to PR's which tried to address those issues? Would you like a more planned approach? Are you less interested in a beyond-ruby-manor Vestibule?

[lazyatom]

I think we are very interested in exploring this.

[h-lame]

Yeah, this would be very useful and interesting.

You should probably look at the euruko 2013 fork. I know they had some of the same problems. I think they might have an approach beyond "just find and replace Ruby Manor" for the theming, but for functionality I think they just coded away on top.

An extension to the "mode" functionality might be good. Maybe putting everything behind a feature-toggle and then elsewhere you define your own modes that control on/off of the feature toggles? I'm not saying this is the only approach I'd be looking for, it's just an idea.

Vestibule was very much written as "what is the bare minimum" to get it working for us. For Ru3y Manor we didn't even have in-code modes and just deployed new code to transition between them.

[fidothe]

I've been poking at this for a little bit now. What I'm thinking is that the route of least resistance involves a two-pronged attack:

1. Move all dynamic(ish) text into translations
2. Encapsulate as much of Vestibule's view-layer code in helpers as possible, with any translations those depend on being clearly documented, and use the helpers as the basis for something like Murray's feature toggle idea.

That would allow either the original rubymanor/vestibule repo, or a new fork, to be refitted with super-minimal HTML, enough to act as easy-to-follow documentation for what needs putting where to get a Vestibule up, running, and skinned.

With that done, I'd want to address my biggest issue with reusing Vestibule, which is that we don't want to let the community decide exactly which talks go in - we're using the voting as a very firm guide, but we found we needed to: filter for multiple talks from speakers appearing in the top X, filter out talks on the same topic, or on the same topic as one of the invited speakers (we're about 50/50 invited / CFP), as well as ensuring that we bias towards diversity if the proposals and the voting give us the option.

My proposal there is that we either make the Agenda stage display talks based on an accepted flag in the database, and add a rake task to accept the top X for people like you guys who can just use the voting straight, or that we introduce Agenda 'modes' so that people can easily add their own criteria. I dunno, but option 1 seems like less hassle there.

With the caveat that people have to be able to deploy to Heroku or similar, I'd like to try and use these changes to make skinning your own Vestibule a matter of changing HTML and config variables, since I think that there are a lot of people who could benefit from Vestibule if there was less donkey work involved in getting it going (me, for example).

Other things I want to think about are: doing a Euroko and whacking in a whole load of Omniauth providers by default, and having them activated by having the relevant keys present in ENV.

Also having a notifications backend that can send email if you want it to. Lack of email caused us some hassles.

I'm planning to get cracking on the UIKonf 2014 edition of Vestibule in earnest early next week, so all thoughts gratefully received.

[h-lame]

None of this sounds bad. All of this sounds good.

We already have some notion of "selected" talks via the confirmed flag for selection. For us this was to allow for voted for talks that could no longer be given, or for dual vote winners, or even for some discretion when two talks had the same number of votes at the bottom of the list.

Looking at app/models/modality.rb it definitely feels like the Rules instances could be extracted into some kind of config file, and then you give each specific vestibule isntance total control over their modes. Of course we'd have to harden up the various actual rules and things that can be can? queried.

Deep in the code there is some mailer notification stuff (there are still settings in config/environments/production.rb) - I think we took it out because for V1 twitter wouldn't actually give you a password, and for V2 github doesn't guarantee one.

I don't know what I feel about multiple omniauth providers, it's a bit confusing for a user I think. But! I appreciate that other conferences might have different audiences that aren't all on github, so this seems like a good feature.

[fidothe]

I was thinking about email notifications more for letting people know that they have suggestions about their proposal, that voting has started (some people with us didn't realise until it was over), that sort of thing.

As far as multiple OmniAuth providers. I agree that multiple providers can be confusing, I think that it would be good to have the plumbing in place so people can pick the most appropriate one for them.

[h-lame]

Agree. (In my above comment where I said "password" I meant "email").

How should we proceed with actually doing this work? Are you planning to work on everything in one go? Now I'm done with the videos I could have some time to help out, but it'd be good to avoid duplicating any effort.
Would it make sense to break all of this out as separate issues and actually assign them to folk who are going to work on them? Don't want to bog anything down in progress, and if you've got most of this worked out in your head and are happy to proceed alone that's fine too!

[fidothe]

One of my tasks for today is to break things out into chunks and open issues for them. I need to get UIKonf 2014's CfP up this week, so I imagine I'll be doing most of it, but help is appreciated!

[fidothe]

I've broken out a few chunks of work to start with in #37, #38, #39, and #40. Objections, ideas, etc. welcome