Basic wiki facilities for Vestibule

[rdrake98]

Applies anywhere you're entering text with Markdown. Anything like [[Paul Battley]] or [[Don't fear the lambda]] should link where you'd expect. (Case sensitive, must get it exactly right.)

Anything unknown like [[Why Pry is superior to irb IMHO]] also becomes a link to create a proposal of that name.

Ownership, withdrawal and voting remain exactly the same. One pattern though might be to create a dummy proposal - like [[Pry]] - just to make some comments on that subject (and a place to link to), withdrawing it from selection right away.

It may be too late for this year. If not, we could chat through refinements.

There's also no optimisation at all. Caching the names hash wouldn't be hard.

[h-lame]

Can we reconfigure this pull request to only include the wiki commit? The other commits don't seem relevant.

Other thoughts:

I don't like [[whatever]] as markup here. Can we use {whatever} instead? Or something equally slim. Perhaps also provide @<twitter_nickname> style shorthand for user mentions?

I don't really see the point in the /moot action either. If we detect our markup but not a proposal or user with the detected title/name/nickname, we could just leave the markup as-is and directly render it. Alternatively we, if we do want to render a link to suggest that someone make the missing proposal we could simply make proposals/new take an optional title param to perform the duties of the moot action without adding the custom action.

Although, there is an issue in that currently, both Users and Proposals are detected by [[whatever]], but if no matching User or Proposal is found, we suggest that the viewer go to create a new proposal, when it may just be a failed User reference.

Differenatiating between proposal detection and user detection (e.g. with @-style for user) might mitigate this.

[rdrake98]

Using rbenv. Only got working (got all tests passing) with mysql2 for some reason. Assume all changes to Gemfile should be ignored if you have a different, rvm setup that's already working for you.

[rdrake98]

Hi Murray, some responses:

1. Just the changes for wiki. Will do, am still a GitHub neophyte. And new?title= is better, clearly.
2. using @hlame and @rdrake98: in the app we're known as Murray Steele and Richard Drake. If that's what I see then that's what I want to link to. I don't want to have to search around for what in the general case is a more nerdy, hidden code for the person.
3. using {My new topic} rather than [[My new topic]]: I wanted something that a) was unlike to occur in text already and b) was familiar usage due to Wikipedia/Wikimedia. But one less character on either side to read is a plus, if it doesn't mess up any existing proposals, suggestions, motivations.
4. distinguishing people and proposals: the original wiki name space flattened this distinction. There are arguments both ways but I think clashes will be rare and this is simplest.
5. Trying to link to a person and getting it wrong due to a typo: agree that it's a bit dumb in this case to see 'Propose a talk - Murray Steel' (or 'h-lame' come to that). But at least you'd realise fast something isn't as you intended. And there's no reason for me that someone might not want to create [[Alan Kay]] or [[Donald Knuth]] as part of the discussion. Knuth almost certainly doesn't have a twitter id!

I would like to attack one aspect of the latter point by giving an immediate visual clue that the proposal or person doesn't exist. Wikipedia uses red for this - I would probably opt in this case for underlined but black. This would tell you you've made a mistake right away, if you know you were trying to link to an existing person or proposal.

Let me do a variant with this simple behaviour, as well as the current one, without the changes to Gemfile. Should be up in the next 24 hours. But keep chatting! The main thing I'm interested in is whether proposals (or ideas, as they'd become in my subversion of Vestibule if anyone let me) should ever have shared editing, as well as univocal suggestions. Cans of worms lie in that direction but it can also be fun, with a reasonably trusted group and without major bot attack.

[rdrake98]

OK, hope that's pretty self-explanatory :)

[rdrake98]

The @nikname markup is more problematic than [[this kind]] I think, as I've explored it, because it's much more likely that someone might choose text for a link with @... inside. A clash with an existing Vestibule user nickname would be bad luck, admittedly, but the preprocessing (before any Markdown) is very simplistic at present.

[[Ruby variables are @hlame imho]] is a bit contrived but would create an anchor link within an anchor link, as will similar text for an attempted Markdown link.

I'd want to write the tests for this and plug the hole to a reasonable degree - or back out of the @hlame idiom I think. But the bigger picture of Ruby Manor logistics is now clearer to me in any case. Will come back to this in some form.

[rdrake98]

By the way, Murray asked

Can we reconfigure this pull request to only include the wiki commit?

The answer (from me anyway, with limited guru-status on Git and GitHub) is I don't know how to remove commits from this little lot. But that's not the place to look to get a feel for this. At the top left of this comment stream, click on Diff and see the five files that I've changed (which now do not include Gemfile of Gemfile.lock). That's all there is to consider and most of it is unit tests. (And it's the tests that have the previous comment, which explains how I know they're lacking.)

[lazyatom]

I wonder how much of the driver for 'wikification' here is a slight misunderstanding of what the suggestions box was for; since it's the only obvious 'discussion' entry I can see why it might be misconstrued as the place to debate various things, but the messaging above it tries to clearly explain that what you should be typing there are questions and constructive criticisms about the specific proposal at hand.

Vestibule's purpose was to try and focus the minds of the community around the development of talk proposals in a more successful way that the mailing list, which was used in previous years. Discussion of arbitrary points was still intended to live on the mailing list.

I personally think any benefits that a wiki might bring to Ruby Manor as a whole would need to be framed in terms of failures of the mailing list, rather than diluting the focus of Vestibule before we're confident that it does it's principle task (focussing the feedback of attendees to improve presentation quality) as well as possible. Could we achieve a significant proportion of the benefit by making the purpose of the suggestions field even clearer, and providing a link to suitable places for more general discussion?

[rdrake98]

No, with respect I don't think it's about the suggestion box. My mental model was affected by not having focused on the mailing list but only slightly. I think in order to be more precise it's important to distinguish three levels of wikification:

1. ability to link to existing proposals and people, as easily as possible
2. ability to create a new proposal - or idea for a proposal - from a non-existent [[Latest Idea]]
3. ability for shared editing of proposals/ideas.

I think the first is a no-brainer. It can only help anyone who uses it and it shouldn't get in the way of anyone else. It would not need to affect a strict view of suggestions. I would expect it to be valuable in explaining motivation and proposals. That's more where I was focused than suggestions.

I think the second level could be really interesting as an experiment, even at this stage of Ruby Manor. There would be still be two kinds of proposals - but I would rename "Withdrawn" as "Idea" (at the view level) and make it the default for creation from a non-existent wiki link. Suggestions on an idea would then feel free to break the strict rule that they are improving a specific proposal, obviously. They might well be trying to improve Ruby Manor as a whole and that could be great.

Now this would change the mental model from only using the mailing list for such things. I understand why you might not want to do that. That's the status quo. I did this bit of coding in my own time at my own risk, because I wanted to play with this idea. I also wanted experience with a GitHub pull request (cool facilities indeed).

I would I think back off level 3, ie changing the single person ownership of proposals. Although level 2 is very different from a "full wiki" that's fine. It would I think enable Vestibule to be used productively to discuss the whole of Ruby Manor, at a cost of very few lines of code.

But, as I said on opening the pull request "It may be too late for this year." I take your point that Vestibule has yet to be assessed in its original conception. No problems sticking to that plan.