This is a complete list of foundation activities. The extent to which we will be able to engage in each of these depends on our funding and staffing.
Lobbying and Networking
We are talking to a wide range of governmental and inter-governmental agencies, institutions, funding bodies, and science publishers: working to convince them that positive policies regarding climate science code need to be instituted, strengthened, and implemented, and that doing so will strengthen the science.
We are also talking to people at these bodies simply to raise awareness of the foundation and the importance of our work, and to build networks between these different organisations. This is an ongoing activity, and is sometimes an uphill struggle but is vital to our long-term goals. When funding permits we hope to hire a staff member specifically for this work
We talk to journalists, write articles (such as this piece in Nature), and will work with science communicators, museums, and outreach specialists. We talk about software, and we also write software to help to explain climate science to the public.
A one-day workshop, for around 25 participants (up to 50), attached to a climate science conference. A morning war-story session, followed by an afternoon tutorial session. The participants benefit from training, exchange of ideas and experience, and take those lessons back to their institutions to share.
The Foundation provides organisation, direction, and tutorials, and publishes the proceedings of the event to stimulate similar work elsewhere.
Direct costs (room, refreshments, materials) met through fees or event sponsors. Estimated Foundation effort 30 days, including admin, preparing presentations, and 2+ staff at the workshop itself. Repeat up to three times per year, at different conferences (e.g. in different specialisms or different regions).
A climate code sprint will be a 2 or 3-day event for a localised or distributed team of up to twenty scientists working on a climate science software project. Held at an institution such as the Met Office, BADC, NCAR, or university department. The participants or project leaders identify problem domains in advance, and through brainstorming sessions and team-programming development sessions, solutions are roughed out, developed, and tested. A few short presentations, tutorials, or lightning talks are scattered through the sprint to break it up and to spread knowledge and expertise.
The participants develop software expertise, broader experience of the project, and team skills. The project benefits from the development and the skill sharing.
The Foundation provides experienced leadership, structure, guidance, expertise, and development effort. We publish all materials, and a write-up of the sprint, to encourage similar and activities improvements elsewhere.
Direct costs (room, refreshment, materials) provided or paid by the institution and/or the project, or by participant fees. Other participant costs paid by their organisations or the project. The institution or the project pays the Foundation costs (including travel and subsistence).
Estimated Foundation effort 25 days, including 2+ staff at the sprint. Repeat up to 5 times per year, for different projects.
A three-day full conference in its own right. Papers, printed proceedings, poster sessions, guest speakers, tutorials, lightning talks, code sprints, ice-breaker, conference dinner, the works.
This may not be appropriate for the Foundation’s first year.
Direct and indirect costs (venue, refreshments, staff, materials) provided or paid for by participant fees and event sponsors. Estimated Foundation effort 60-80 days, including all staff attending the conference. Repeat regularly (every year? every two years?)
We will attend climate science conferences and workshops several times per year, to meet climate scientists, to encourage code-related networking, and to promote the Foundation goals of open-ness and software quality. The Surface temperatures workshop in Exeter in September 2010 is just the first example. There are numerous annual conferences and events; we will have to pick and choose.
Every technical member of the Foundation should attend at least two events per year, for professional development and to maintain the Foundation’s profile in climate science. They should apply to make a Foundation-related presentation at every event attended.
Attending such an event is 5-8 days’ effort, including preparation, travel, conference, write-up. Additionally, writing a new presentation is about 5 days’ effort (see “give guest seminar” below).
Writing Scientific Papers
As resources permit, we will both write papers and contribute to papers led by other authors.
Being the lead author on a scientific paper, including preparation for publication, responding to reviewers, etc, is approximately 20 days’ effort (in addition to the work described in the paper).
Collaboration on a paper, sufficient for a co-author credit, is approximately 5 days’ effort.
Foundation members have several specific ideas for papers to write, and one is currently working on a collaborative paper.
Give guest seminar
Presenting a seminar and participating in subsequent discussion at an institution. This may be as part of a regular seminar program, for example that of The Centre for Atmospheric Science at the University of Cambridge. The Foundation gains a relevant audience for our message, igniting a passion for openness amongst scientists themselves. Seminar programs often give the working scientists an opportunity to “look up from the microscope” and think about problems of broader concern or beyond the next funding deadline.
Direct costs (room and maybe refreshments), are expected to be borne by the institution, but not all institutions will be prepared to cover travel expenses (of about 200 GBP to a UK institution).
The large cost of a seminar is in the creation, but once created, it can be delivered with only small modifications for a lowered repeat cost. Preparation is approximately 5 days’ effort; each delivery is approximately 2 days’ effort.
Blogging engages with a wider audience which includes scientifically literate members of the public, and scientists who are interested in non-traditional means of peer communication. Such groups are directly relevant to the Foundation’s objectives. A blog article need not be prepared with the care and attention to detail that a scientific paper merits, and they may be produced and published rapidly in response to particular events. Material worked up as a blog post may later find its way into white papers / seminars / and possibly even scientific papers.
A typical post will take approximately 2 days’ effort, including managing responses. The blog is a vital part of the public face of the Foundation, and we will make blog posts at least 12 times each year.
Preparation of a detailed “white paper” that encapsulates a particular advocacy position or describes best practice (for example, “How do I make my code available?”, or “should peer-reviewers request code?”). These form a permanent resource and a service to the scientific community. They can arm people who are already keen to promote our objectives and enlighten people who are not yet aware of the issues.
A typical white paper will take approximately 10 days’ effort. In our first year we aim to provide at least four white papers. Each white paper will reviewed annually to check that it remains current, and a white paper can be expected to have a useful lifetime of 3-5 years.
Creating an online directory of code resources in climate science. Resources will be assessed for openness (how easy is it to get the code, what can I do with it once I’ve got it?) and linked to supporting materials (scientific papers, documentation, visualisations). We would intend for it to become the “one-stop shop” for access to existing climate science source code (by scientists and others). The directory would also be used by the Foundation to measure and monitor the openness of climate science, and become one of the measures by which we can judge our success (“we have opened 6 projects and 5 million lines of code in 1 year”).
This is closest in form to our previous work in the software industry and we would manage it as a software project. Software projects are never completed – and this directory will be an ongoing process as more software is published – but an initial full scale version will be approximately 50 days’ effort. We will use an incremental approach to delivery, so it should be possible to deliver something minimal but usable for only an initial portion of that effort.
This is a general heading for Clear Climate Code work similar to our existing ccc-gistemp reimplementation of NASA’s GISTEMP software. Following the success of that project, several climate science groups have expressed interest in our rewriting their codebases to improve clarity or consistency. Such a project could be performed intensely over a short period, or gradually over months or years, depending on resource availability.
Because of the large volume of software in climate science, we could spend all our time and resources on this. We need to choose code bases with care, identifying ones with particular public interest or which might best serve as best-practice examples to the climate science community.
The ccc-gistemp project also continues, as we develop visualisations and variations.
This work might form the basis for research leading to publication of science papers (see above).
We will prepare and deliver training sessions to groups of climate scientists. Topics to cover would include: code clarity, system maintainability, documentation, use of source code management tools, agile and evolutionary development practices, test development, code review, defect tracking, code publication.
We could deliver 1-day, 2-day, or 5-day courses, for groups of 5 to 20 participants. Courses would usually be hosted by an institution, which would meet direct costs and pay day rates for the training. Courses should be delivered by two staff members working together. There is really a continuum between training courses and code sprints (see above), and we expect to tailor provision according to the client.
We will need to spend some effort preparing training materials. Once prepared, the same course could be delivered multiple times.
Code review and document
This service would be related to a code rewrite, but much quicker. An institution or group would ask us to take a look at a body of code (we have already received a few such approaches). We could review the code or assess the practices and write a report. The report might include documentation for the code base, recommendations for improvements or extensions, and a list of defects found.
Such code review activities would usually include one or two institution visits, but most of the work could take place off-site.
There are a wide variety of functions we could perform as external software consultants in a climate science group. Perhaps the most obvious is a process audit, which is broadly similar to a “code review and document” activity (see above), but would cover software development practices instead of a body of code. We would study software development, interview scientists and other staff, and write a report making recommendations for improvement.
Generally consultancy would take place at an institution, which would pay day rates plus travel and subsistence.