Ethan White

1.  If you don't have an easily accessible RSS feed available (and by
    easily accessible I mean in the browser's address bar on your
    journal's main page) for your journal's Table of Contents (TOCs),
    there is a certain class of readers who will not keep track of you
    TOCs. This is because receiving this information via email is
    outdated and inefficient and if you are in the business of content
    delivery it is, at this point, incompetent for you to not have this
    option (it's kind of like not having a website 10 years ago).
2.  If, for some technophobic reason, you refuse to have an RSS feed,
    then please, pretty please with suger on top, don't hide the ability
    to subscribe to the TOCs behind a username/password wall. All you
    need is a box for people to add their email addresses to for
    subscribing and a prominent unsubscribe link in the emails (if you
    are really paranoid you can add a confirmation email with a link
    that needs to be followed to confirm the subscription).
3.  Most importantly. Please, for the love of all that is good and right
    in the world, DO NOT START AN RSS FEED AND THEN STOP UPDATING IT.
    Those individuals who track a large number of feeds in their feed
    readers will not notice that you stopped updating your feed for
    quite some time. You are losing readers when you do this.
4.  If you have an RSS feed that is easily accessible (congratulations,
    you're ahead of many Elsevier journals) please try to maximize the
    amount of information it provides. There are three critical pieces
    of information that should be included in every TOCs feed:
    1.  The title (you all manage to do this one OK)
    2.  All of the authors' names. Not just the first author. Not just
        the first and last author. All of the authors. Seriously, part
        of the decision making process when it comes to choosing whether
        or not to take a closer look at a paper is who the authors are.
        So, if you want to maximize the readership of papers, include
        all of the authors' names in the RSS feed.
    3.  The abstract. I cannot fathom why you would exclude the abstract
        from your feed, other than to generate click throughs to your
        website. Since those of you doing this (yes, *Ecology*, I'm
        talking about you) aren't running advertising, this isn't a good
        reason, since you can communicate the information just as well
        in the feed (and if you're using website visits as some kind of
        metric, don't worry, you can easily track how many people are
        subscribed to your feed as well).

If this seems a bit harsh, whiny, etc., then keep this in mind. In the
last month I had over 1000 new publications come through my feed reader
and another 100 or so in email tables of contents. This is an incredible
amount of material just to process, let alone read. If journals want
readers to pay attention to their papers it is incumbent upon them to
make it as easy as possible to sort through this deluge of information
and allow their readership to quickly and easily identify papers of
interest. Journals that don't do this are hurting themselves as well as
their readers.


If you don’t have an easily accessible RSS feed available (and by easily accessible I mean in the browser’s address bar on your journal’s main page) for your journal’s Table of Contents (TOCs), there is a certain class of readers who will not keep track of you TOCs.

A message to journal editors/managers about RSS feeds

<div>

A few months ago Mike Kaspari over at [Getting Things Done in
Academia](http://eebatou.wordpress.com/) emailed me to ask "[how do you
use your Lab Wiki? Has it been worth it?". I sent back much of what is
included below and Mike asked if he could use some of my thoughts for a
post on wikis. I of course said yes, but since GTDA has been silent for
quite a while now I figured I'd go ahead and post on it
myself.]{.Apple-style-span}

</div>

<div>

[  
]{.Apple-style-span}

</div>

<div>

[First, for those of you whose only exposure to wikis is wikipedia, a
wiki is basically just a group of web pages that can be edited online
(i.e., inside a browser). These pages might be editable by anyone (like
wikipedia) or only by users with permission. They also might be viewable
by anyone, or only by a small set of people. For a lab wiki I'd
recommend that most of the wiki only be accessible and editable by
members of the lab with some areas accessible by specific external
collaborators.]{.Apple-style-span}

</div>

<div>

[  
]{.Apple-style-span}

</div>

<div>

[So, why have a lab wiki?]{.Apple-style-span}

</div>

<div>

[  
]{.Apple-style-span}

</div>

<div>

1. [ ]{.Apple-converted-space}Collaboration -- The wiki provides a
central place for idea development, conversation, posting of results and
interpretation, etc. It is particularly valuable for remote
collaboration in that it switches the paradigm from one or a few people
taking the lead and dealing with keeping everyone else informed to a
system where it is the participants responsibility to keep an eye on
what is going on and everyone decides their own level of involvement.

</div>

<div>

  

</div>

<div>

2. [ ]{.Apple-converted-space}Idea generation, motivation and storage --
Have you ever had a cool idea but didn't have time to think about it at
the moment. I jot down 2 sentences on the research ideas page of my
wiki. The idea of this page is to put interesting ideas out in front of
larger audiences and see if anyone is interesting in working on them.
This has already lead progress being made on one project that I wouldn't
have gotten around to otherwise. At the very least the idea is there for
later if I want to go back to it myself.

</div>

<div>

  

</div>

<div>

3. Progress in small steps -- If I have an idea about something, even a
small one, I just login and jot it down on that projects page. If I have
20 minutes of spare time I can do one simple analysis, or learn how to
do a single step in an statistical or computational problem and post the
answer. A small step might allow one of my collaborators to make their
next step on a project, or seeing progress may motivate them to do
something themselves. In general I find that this medium encourages and
allows progress to be accomplished with more smaller steps, thus
lowering the activation energy for some projects.

</div>

<div>

  

</div>

<div>

4. [ ]{.Apple-converted-space}Information aggregation -- When someone in
the lab finds a useful tool, good advice on some academic task (e.g.,
[writing
papers](http://eebatou.wordpress.com/2008/07/23/on-writing-better-kurt-vonnegut/)),
etc. this information can be stored on the wiki. This sort of thing can
be done via email or via blog, but I think that permanent archiving in
well structured pages combined with the inherently improved potential
for participation by members of the lab makes the wiki superior for this
task. For example, a third year student who is starting to write papers
in 2012 can just go to the wiki page on advice for writing and get
going. If I'd just emailed the relevent link to my current students then
it won't reach future students and it won't even reach many current
students at a time when it's useful to them.

</div>

<div>

  

</div>

<div>

5. [ ]{.Apple-converted-space}Lab openness -- Most of the pages on our
wiki are open to anyone in the lab (though we do have the ability to
restrict access and do for outside guests and in a few other
circumstances). My hope is that this will help with a variety of minor
issues I've observed over the years (not in my labs, but in labs I've
been a member of and/or known people in) including territorial disputes
resulting from a lack of communication and the classic graduate student
mistake of thinking that because it took your advisor three weeks to
read your paper that it's because they're at home playing Xbox all
evening. I don't know if this will work but my feeling is that openness
is in general a good solution to a lot of problems and the wiki makes
such openness happen almost by default and provides a historical record
for cases where disputes still occur.

</div>

<div>

  

</div>

<div>

So, that's my plug for having a lab wiki. There are a variety of ways to
setup a wiki, with the easiest being to use one of several online hosts.
We use [PBwiki](http://pbwiki.com){target="_blank"}, which I can't say
enough great things about, but there are a variety of options. Many of
these wiki sites have full WYSIWYG editors so editing a page is just as
easy as editing a Word document. So, go find a wiki provider, set up a
free wiki, and try it out. Maybe you'll find it as essential a tool for
a modern academic lab as we do.  

</div>


A few months ago Mike Kaspari over at Getting Things Done in Academia emailed me to ask “how do you use your Lab Wiki? Has it been worth it?”. I sent back much of what is included below and Mike asked if he could use some of my thoughts for a post on wikis. I of course said yes, but since GTDA has been silent for quite a while now I figured I’d go ahead and post on it myself.

Publicaciones de Rogue Scholar

A message to journal editors/managers about RSS feeds

The benefits of having a lab wiki