Digital Tools for Bringing Evolution to Everyone

Abstract

Evolutionary Studies (EvoS) programs, conceived of in the terms elaborated by David Sloan Wilson in his book Evolution for Everyone, are intrinsically interdisciplinary. They are also intended to bring individuals and organizations outside the university teaching and research environment together with academe. Internet technologies in use at present are designed for the purpose of promoting such collaboration and community building. This paper explains several such technologies, describing their best uses and the differences between them, in the context of a project management framework.

Collaboration in a Digital, Networked Environment

Evolutionary Studies (EvoS) programs, of the kind proposed and initiated at SUNY Binghamton by David Sloan Wilson and colleagues, are notable not just because they aim to promote the understanding of evolution but because they aim to explore ways in which evolutionary thinking can enlighten and change how we live. When EvoS programs are considered broadly, they are, in a sense, directly applicable to all of our pursuits. In the larger vision elaborated by Wilson in Evolution for Everyone (Wilson 2007) and online at http://evolution.binghamton.edu, an EvoS program requires collaboration across departmental and disciplinary boundaries. Explaining human cognition, emotion, and forms of social organization requires the joint effort of psychologists and evolutionary biologists. This kind of cross-departmental collaboration is not uncommon nowadays. “Hybrids” such as molecular evolutionary genetics, ecology and evolutionary biology, and systems biology, for instance, require the expertise of researchers whose skills require a lifetime to master. These collaborative endeavors have been recognized in the academic context by the formation of interdisciplinary academic departments and research institutes. What is really novel about the scope of EvoS projects is that they aim at collaboration among people across the full range of contexts in which our lives take place. This extended circle of participants creates an opportunity for those contributing to an EvoS project to use their understanding of evolution to improve their own lives and the lives of those around them.

Collaboration on this scale is especially challenging. Scientists in different disciplines must work hard to find what they have in common. They have the advantage of understanding one another’s roles in academic and research environments and of looking at the same portions of the physical world, even if from different perspectives. Mathematical tools are, in many cases, shared. All share the aim of learning from experience by observation and experiment. Collaborations linking academic departments with institutions and individuals outside of academia are faced with a greater challenge.

Fortunately, there are a number of applications for use in a digital, networked environment that are designed to handle logistics, communication, and the integration of work contributed by all team members, freeing up collaborators to focus on the substantive intellectual and practical problems that need to be solved for their project to succeed. These applications include wikis, threaded mailing lists, blogs and microblogs, versioning software, social networks, and bibliography sharing platforms. The aim of this paper is to explain each of these in terms useful for EvoS projects. (See Table 1 for an overview.) I begin with a sketch of the project management approach to collaborative work, which illuminates the differences between these tools.

Table 1 Overview of digital networked tools for collaboration

Planning is Essential

Integrating plans for creating an online collaborative environment into plans for the project as a whole is a must. Failing to do so will almost certainly result in frustration and waste time, money, and expertise at a level potentially fatal to the project. Because almost all of the tools I discuss here are available for free under open source licenses, the cost of acquiring them is usually negligible. The expertise required to install, maintain, and help project collaborators use the digital tools is not, unfortunately, free. The project plan should identify a team member responsible for supporting the project’s digital framework for collaboration, either directly or by way of working with a university IT department or other network provider. A strategy for the use of the digital tools should also be explicitly described in the initial planning documents for the project as a whole. This paper is intended to help project planners develop such a strategy by describing which tools are best suited for particular purposes.

A Project Management Perspective

“Project management” describes a method for organizing and executing a collaborative endeavor that has a definite end point; this, having a definite end point, is what differentiates a project from a permanent position. A scientific investigation funded by an NSF grant, for instance, is often a project: Support for the project continues for a fixed term, and the group of people supported are expected to have reached a definite goal by the end of that term. In contrast, a faculty position or lab technician has duties essential to the functioning of the college or lab, respectively. They may be filled by different people in succession, each of whom may carry out projects while filling the position, but they are necessary for the continued operation of the larger organizing framework of which they are a part. People, money, space, and other support resources must be allocated for as long as the larger organizing framework has a given set of goals, for instance, undergraduate teaching or support of laboratory scientists.

Although the literature on project management is extensive and, in some cases, forbiddingly technical, the central ideas are easy to grasp.¹ Planning a collaborative project is much easier, and the project has a much greater chance of success if these central ideas are used as a touchstone during the formative stages of the project.

Agree on the Goal

What criteria are going to be used to determine whether the project is successful? In the case of an EvoS project, promoting collaboration across disciplines and among individuals will probably be a goal in itself. This will be assessed at the end of the project, perhaps by a discussion or survey among participants. The end products of an EvoS project will most probably be intended to support teaching, research, or the completion of a resource explicitly aimed at bringing evolution to everyone. Another important aspect of agreeing on the project’s goal is to understand the value of the project for different groups of people. These include students and contributors, present and future; administrators such as department chairs or deans; IT support staff; and faculty facilitators; and “everyone”—individuals and institutions in the community at large.

Identify Skills

What can each contributor to the project do? Is there someone who has computer programming or HTML coding experience? Someone who has ties to an organization in the community, for instance, a school, senior center, community garden, or research group? A person particularly well-suited for leading a small team? A graphic designer or copy editor? Someone who is an authority on a certain scientific theory or natural phenomenon? Is there someone particularly interested in learning a certain skill or about a certain topic if no one in the group is already an expert? The goals of the project must be established relative to the kinds of skills that can be brought to bear by the project team.

Understand Your Resources

“Resources” is intended broadly. How much money is available? How much time do the various contributors have? Is a classroom, meeting room, or office required? What computing resources are required? Will academic schedules limit the availability of some participants’ involvement? Travel? Intangible resources such as good will and reputation might also be accounted for. As in the case of team members’ skills, a project’s goals are limited by the resources available.

The idea that these three tasks ought to be considered is not particularly profound. Nonetheless, it is strongly advised that they be completed in an explicit manner with the input of as many team members and stakeholders as possible. Doing so increases the project’s chance of success significantly.

These tasks are not primarily logistical or technical in nature. They concern the aspirations of the collaborators for what the project should be and their sense of how the project’s scope must be limited so that its goals are realistic. Why is the project important? What needs will it fill and for whom? What are the values that the project will exemplify? Is the project a model or proof of concept, or is it the full-scale implementation? Are esthetics and design excellence important, or is spare, simple design sufficient, so long as other goals are accomplished, for instance, access to electronic resources, messaging, or gathering community input on an important topic? How will documents and software created as a part of the project’s aims be distributed, and what intellectual property concerns are there? Will public domain materials be used? Copyrighted material? How much responsibility will the various contributors be expected to shoulder? For instance, should students be responsible for communicating with outside groups? How much will the opinions of undergraduates, graduate students, college faculty, and others be permitted to alter the goals or work processes?

Unlike the preliminary planning stages, the next set of major planning tasks concerns the details of the means to be employed to realize the project goals. Working in a hierarchical manner is often successful: first, determine the “sub-tasks” that must be completed in order to realize project goals; next, determine what “sub-sub-tasks” must be completed to accomplish the sub-tasks; and so on. After having identified the tasks and having determined which must be completed before others can be, the group must estimate the amount of time each task will probably take, identify contributors best able to complete each of the tasks, and set deadlines.

Two points mentioned above are of special importance. First, each task must be assigned to a particular team member, so that he or she is accountable for whether it gets done to the specifications of the project plan. The entire team must be able to identify the individual responsible for each task, so that members can consult with one another about tasks dependent on one another. Second, the deadline for completing each task must be explicit to everyone. The point of determining the sub-tasks required to accomplish a larger task is to be able to gauge whether the project is on schedule. Even people with the best intentions tend to over-estimate their progress; perhaps they misjudge what is required.

The third and last stage of setting up the framework for a successful collaborative project is establishing how the team members will communicate and who the main contact people and leaders of the team will be. No doubt we all know a colleague who never returns phone messages but responds immediately to email. If the team is going to accommodate this person, everyone must be prepared to check email regularly. Regularly scheduled meetings attended by all should be scheduled. As will be seen below, digital technology offers an especially rich array of communication tools, each tailored to different needs.

Finally, there must be some individuals who are responsible for keeping track of whether the various people and sub-groups are on track. In an academic setting, a teaching assistant might fill this role—as well as evaluating students by whether they complete their work on time. The person keeping track of whether the tasks are being completed on time need not be a superior or leader but may act more as a facilitator. If tasks are not being completed on time, the coordinator should find out why. Perhaps one person has been ill, or perhaps some task is taking much longer than anticipated. This can become delicate because the coordinator may discover that some team members are not putting in the work expected of them. The coordinator must be prepared to motivate others to increase their level of commitment, or to contact a leader or authority who can do so.

In the main section of this paper, below, I describe each of the various digital tools in terms of how they can contribute to the growth of a project administered using the project management technique just elaborated:

• Tracking the progress of the project, necessary for team members and project coordinators

• Providing a forum for individuals in different institutional contexts and roles within the project for sharing knowledge and for working out logistical details required for completing tasks

• Open clear channels of communication with each individual responsible for a particular task, so that expectations are known in advance and well understood and so difficulties can be resolved smoothly

• Providing a mechanism for quickly identifying resources outside the project staff and facilities and distributing them to those they are most likely to be of use to

• Informing those outside the project of its aims and activities

The Wiki

Due to the success of Wikipedia, the wiki is probably one of the best-known digital tools for collaboration. A wiki, in essence, is a website whose content can be edited by any member of a given community and whose purpose is to share information about a topic that concerns them. Wikipedia places no restrictions on who may alter site content, and it is intended to be a forum for information about everything. The information added to project wikis usually includes advice; tips; instructions or recommendations about how to proceed in particular circumstances, say, a certain laboratory protocol; and links to other useful sites. A wiki is a good site for distributing documents likely to be of use to everyone working on the project. The wiki need not be accessible by those outside the project. Wiki software platforms are designed for ease of use, allowing users to add new sections of the wiki site, modify the work of others, or add new material within the context of the sections already present.

A wiki would be of particular use to an EvoS project because it can be used as a reference. The knowledge and skills of contributors to the project can be expected to vary; the wiki provides an excellent mechanism for experts from different areas to share what they know. For instance, a wiki would be an excellent place to publish a glossary of terms about evolution; a description of basic models of the evolutionary processes; or an outline of ideas about art, economics, cuisine, or some other subject under study.

Although users can add new sections or pages to a wiki, the plan of organization of the wiki is fixed. Information can be added, edited, or removed, but once created, the information remains stable within a static navigational scheme. Because of this, users can locate material easily and come back to it. For this reason, a wiki is not useful for posting updates about a project, or for discussion. Wikis are not good for recording the development of an idea or document; new content replaces the old. For news and, to a limited extent, for discussion, a blog is the proper tool, and for extended back-and-forth discussion, a threaded mailing list is ideal.

The Blog and the Microblog

The essence of a blog is that it is organized chronologically. New content is added and identified by the date and time it was posted. Some blogs may be intended only for project contributors, updating others about the state of their work at the time of posting, perhaps calling attention to issues or difficulties, or indicating that a certain milestone has been passed. Although some people use blogs to explain how they solved a problem, a wiki is a better place for this. Blog posts recede into obscurity as more are added; relevant information is easier to find within the static navigational scheme of a wiki than by browsing or searching blog posts. Users can comment on blog posts, but, as mentioned above, a threaded mailing list is the tool best suited for exchanging ideas in conversation. Blogs intended for the general public are excellent for keeping the broader user community informed about how the project is developing and relating interesting or important insights gained along the way.

Microblogs

The microblog is a cousin of the blog because microblog posts appear in chronological order. Nonetheless, they are quite different. Microblog posts are short, no more than 140 characters on the Twitter microblogging service (the best-known microblogging platform). Posts are ephemeral. If a user wants to receive the posts of another user, the former subscribes to the latter’s “feed.” By subscribing to many feeds, a user will see a column of text, more being added as each new posting appears from one feed. Users can respond to a particular posting, forming a conversation-style exchange. Users can also forward posts that appear in their feeds to their subscribers.

Microblogs are not good for keeping others informed of a project’s progress, or for indicating that a milestone has been passed. A microblog is best used for forwarding links to feed subscribers. Posts might announce a new blog posting, a publication, or a link to another site. Because microblog posts soon disappear from view as a user’s feed accumulates new posts, it is advised to re-post several times. Microblogging can be particularly effective because users interested in the project will subscribe to the project’s feed. They will also forward posts to their followers, some of whom may not subscribe to the project feed. Accordingly, subscribing to the feeds of microbloggers who post about topics of interest is a good way to find out what others are reading and talking about. The method is to identify a microblogger whose posts are valuable and see who else subscribes to his or her feeds. Some of these will post about the same topic and will be worth subscribing to. In this way, groups of microbloggers form networks built on common interests.

To be effective, posts must be frequent (several times a day or more) and informative. The aim is to build up an expectation among subscribers that they can learn about the project and take advantage of the work of its contributors. If posts are not frequent enough, many feed subscribers will not see any of the project’s posts at all, on a given day. Likewise, if microblogging is going to be relied upon as a source of information and contacts, the stream of feeds must be checked frequently. They appear and disappear quickly, and it is easy to miss useful postings. Designating a certain individual to maintain and observe the project’s twitter feed is strongly advised.

The Threaded Mailing List

A threaded mailing list is the best means of conducting exchanges requiring discussion of complex subject matter or fine points of detail. A mailing list is a software package installed on a mail server that routes email to list subscribers who send mail to the list address. A “thread” is an exchange of email messages about the same topic or issue. Suppose that one list subscriber is confused about a point raised by John Maynard Smith in one of his arguments against group selection. This user sends a message to the list address with a subject line that identifies the topic of the email. Mail from users responding to the initial message using the “reply” function of their email clients will be displayed in a hierarchical list. The discussion can proceed in real time if many users are online at once; it can also proceed asynchronously, that is, users may enter the discussion hours or days after it began, responding to one of the messages in the list. By means of the prefix added to the subject line of list messages, list members can quickly identify them and can configure their email clients to direct them to a folder created to isolate them from others arriving in the user’s “inbox.”

Mailing lists are often used to generate material for a wiki. The list serves as an arena for brainstorming. A subscriber encounters a problem or issue; he or she turns to the other list subscribers for discussion. After group members have worked out a solution, they discuss what should be added to the wiki to help others who encounter the same problem or issue. Discussion of the wiki entry can often be involved, focusing on the entry’s language as well as its content.

Some individuals avoid the use of threaded lists, creating what they believe to be the same effect by sending a message to many people at once by entering many email addresses to the “to” or “cc” field. The expectation is that recipients of this email will use “reply all” to inform the other addresses of their responses. This practice is not advised. Neither those excluded from the set of initial addressees nor those excluded from the “reply all” responses will be included in the discussion. This is anathema to successful collaboration. As well, there is no standardized subject line header that can be used to quickly identify or re-route messages sent to each individual.

Shared Bibliography Online

Individuals maintain personal bibliographic databases for several reasons. First, the database keeps a record of sources that have been useful in the past or that contain important or useful explanations, report important results, or are useful for general reference. Second, good research practice requires documentation. A database of bibliographic references is a useful supplement to manuscript drafts and notes used in the research process. If a digital copy of a work or a link to one is obtained, its bibliographic reference serves as an aid to locating it. Records for particularly important works can be annotated with summary points or page references. Third, the bibliographic database can be used to insert citations and format references in a final draft.

Sharing references in a central repository accessible by all project participants offers the same benefits to a group. The collective database will be more comprehensive than any one person’s. Collaborators from different subject areas and institutions can point out works to be consulted for a quick introduction to key ideas or practices. Digital copies can be easily acquired by anyone in the group. Works authored by multiple collaborators can easily coordinate research, drafting, and the production of a final draft.

Versioning

How can multiple authors contribute to a single document? Even two or three authors are likely to have difficulty. If there is to be a single “master copy,” perhaps shuttled back and forth between collaborators by email, will several collaborators be able to work on it at once? How will successive versions be distinguished from one another? Is there any way to make sure that all collaborators know which copy of the document is the latest? What if one person adds a sentence which is subsequently rewritten or deleted? Will other collaborators be aware of these changes? Versioning software, also known as version control software, is designed to solve these kinds of problems. Version control software maintains a database with the history of changes made to a document; users work on a copy of it on their personal computers and upload changed documents to the central repository. The software merges a user’s changes into the master copy of the document, in the repository. It verifies that another user has not made conflicting changes, for instance, rewriting sentences that another user also rewrote. In such cases, the software does not merge the document with the master but rather notifies the individuals whose changes conflict. They must work out what changes they want to keep; when they have resolved their differences, the changes can be merged into the most recent copy of the document. Because the software keeps track of changes, a document or part of a document can be “resurrected”: previous versions or parts of previous versions can be merged with current versions of a document or set of documents. Historical record keeping is also a hedge against hard disk crashes, accidental deletions, or corrupted files. A user’s personal copy of the documents may be destroyed, but the copies in the repository can be downloaded to the user’s machine.

There are fewer graphical user interfaces for version control software than there are for word processing, spreadsheets, or web page coding utilities. Nonetheless, those available are sufficiently full-featured and easy to use that, within an hour or so, an undergraduate who feels at home with computers can perform the basic tasks needed to keep collaborative documents up to date. In case of conflicts, which are rare, or in case a user makes a mistake when updating, it is recommended that there be a central version control “super-user” who can troubleshoot.

Social Networking

Social networking is without doubt the most widely used networked collaborative tool in the world: the enormously popular site http://www.facebook.com is the paradigm example of social networking software. The distinguishing feature of social networking software is the graph structure by which information about an individual is linked to information about another. A graph of the kind used in social networking software consists of edges and nodes. If two nodes share an edge, they are related. Visually, as seen in Fig. 1, a graph is simply a set of lines (the edges) whose common end points are represented by circles or other shapes (the nodes). In an online social network, each node consists of a group of web pages representing a particular person or other entity such as an academic department, working group, research institute, project, non-profit group, or simply any group of people who share some affinity. A user can discover connections between individuals by following edges originating at a person’s profile page.

Fig. 1

A graph structure, representing relationships between individuals represented at the nodes. The lines connecting each individual on the graph are edges. Each edge represents a particular kind of relationship between two individuals. This graph represents a number of important relationships between the various individuals; these relationships would most likely be of interest to a working group for collaborators with knowledge of a certain subject area, familiarity with a shared body of experimental techniques, and, perhaps most importantly, a high level of comfort working with one another. The graph shows an academic lineage, connecting university faculty who have worked together previously with two generations of their students, who have expanded and strengthened the connections among the group

As its very description suggests, social networking software is excellent for discovering relationships between people and groups of people. This can be especially useful if collaborators are not likely to know one another, their educational or professional backgrounds, the kinds of projects they have worked on in the past, or the other individuals they collaborated with. Because EvoS projects are intended to bring together people from otherwise disparate contexts, social networking software should be expected to play a significant role in identifying collaborators and organizing them into productive working groups.

Concluding Remarks

Wikis, threaded mailing lists, blogs and microblogs, social networking, and shared bibliographies are excellent means for building collaborative relationships. Though many people are familiar with some of these tools from everyday use, everyday use can obscure the differences between them. While each is excellent at carrying out the functions for which it is designed, their versatility is limited. Collaborative work and building community is intrinsic to the EvoS program’s central motivation and icon, “Evolution for everyone.” In many cases, new technologies are adopted simply because they are new. In the case of the network tools described here, the reverse is true: The EvoS program, itself a new endeavor, fits nicely with the aims and best uses of the already-existing digital networked environment. An EvoS program failing to adopt a strategy for exploiting that environment will fail to reach its potential.