The Conference Manifesto: 10 Steps to a Better Conference

Acceptance to the conference could be contingent upon the speaker reading and signing an agreement to meet the following criteria in their talks:

1) I understand that the conference paper should do something that an article cannot. Since it involves direct, real-time contact with other humans, the speaker should make use of this relatively rare and thus precious opportunity to interact meaningfully with other scholars.

2) I will not read my paper line by line in a monotone without looking at the audience. I needn’t necessarily abide by some entertainment imperative, with jokes, anecdotes or flashy slides, but I will strive to maintain a certain compassion toward my captive audience.

3) I understand that a list is not a talk. I will not simply list appearances of a theme in a given corpus.

4) I will have a thesis, and if I don’t, I will at least have a reason that my talk should exist.

5) I will keep direct citations to a minimum, not relying on them to fill up time. I understand that audience members shudder at lengthy blocks of text in the PowerPoint or on the handout.

6) In the Q. and A., I will not ask an irrelevant question for the sake of being seen asking a question. If my question is hyperspecific and meaningless to anyone but myself, I will approach the speaker after the talk with my query.

7) I will not make a statement and then put a question mark at the end to make it sound like a question.

8) If I ask an actual question, I will a) not take more than a minute or so to ask it, and b) ask it politely even if I disagree with the speaker.

9) I respect the time of my colleagues who’ve come to hear me speak. I will do my best to be as clear and succinct as possible, and make their attendance worthwhile.

10) I understand that if I disregard these recommendations, I might be complicit in the death of the humanities.

Source: The Conference Manifesto

This is aimed at academic conferences in the humanities, but it applies equally to academic conferences in law and to many tech conferences. CALIcon would be an even better conference if presenters and attendees kept these things in mind.

Adding custom slash commands to Slack

Slack’s custom slash commands perform a very simple task: they take whatever text you enter after the command itself (along with some other predefined values), send it to a URL, then accept whatever the script returns and posts it as a Slackbot message to the person who issued the command. What you do with that text at the URL is what makes slash commands so useful.

For example, you have a script that translates English to French, so you create a slash command called /translate, and expect that the user will enter an English word that they’d like translated into French. When the user types /translate dog into the Slack message field, Slack bundles up the text string dog with those other server variables and sends the whole thing to your script, which performs its task of finding the correct French word, chien, and sends it back to Slack along with whatever message you added with your script has, and Slack posts it back to the user as The French word for "dog" is "chien". No one else on the team will see message, since it’s from Slackbot to the user.

— via Creating Custom Slash Commands for Slack

Great tutorial walking you through one of the many useful features of Slack. This will get included in the CALIcon15 session.

Apache Allura is an open source repo/project management system

Apache Allura is an open source implementation of a software “forge”, a web site that manages source code repositories, bug reports, discussions, wiki pages, blogs and more for any number of individual projects.

Source: Apache Allura™ / Wiki / Home

Looks like it could be a good alternative for folks looking for something that is not Github to help manage code and projects. Written Python, uses MongoDB as its dbm, search is SOLR powered.