Although we do our best to ensure that our wiki content is valuable, the documents within it have not undergone our rigorous Quality Assurance process.
Often, documents that are intended to become briefing notes on our website start life in the wiki. This page records which briefing notes are currently in production. It also records the briefing document that each OSS Watch team member is likely to write next. Finally, it records proposed briefing notes so that there is a pot of suggestions ready to be allocated once a document has been finished.
1. Assigned Documents
This section records all the document that have been assigned regardless of whether they are being developed in the wiki or using other workflows. The allocated date allows us to keep track of how long it is since the document was assigned to the author. The deadline is the latest agreed date for circulation of a polished draft for team review. The "To Elizabeth" deadline is the date that the doc needs to be with Elizabeth for editing in order to make the deadline for team review.
Author |
Document |
Description |
Allocated |
To Elizabeth |
Deadline |
Comments |
Ross |
Software sustainability maturity model |
A proposal for a research software sustainability model |
Sep 2009 |
26 April |
15 Sep 2010 |
Now with EB for final approval before publication |
Rowan |
How to become a developer in the mobile space |
|
April 2010 |
|
1 Sep 2010 |
|
Gabriel |
|
|
|
|
|
|
Sander |
Release management |
|
Feb 2010 |
27 May |
1 June 2010 |
All comments in; to be addressed after 16 August |
2. Pending Documents
These docs have been agreed as the next document for each author. Work will only start on the next doc once the assigned doc has been finished. From August 2010 all documents will need to relate to the support plan (authors will need to demonstrate relevance, GH to decide priorities in relation to the support plan).
Author |
Document |
Description |
Rowan |
Licence differentiator |
Turning text embedded in app into a doc |
Gabriel |
Video doc |
GH to start doc in wiki, then doc will develop into qa'd doc for website |
Sander |
Wookie case study |
Draw on existing wiki docs |
3. Proposed Documents
Team members can add to the proposed documents list at any time. At each month's review day any author can request that their current pending doc be replaced with a proposed doc. This is a way for us to respond to new demand or changing priorities for a specific doc.
Potential author |
Document |
Description |
Comments |
|
GetOSSWatchFundingAdvice |
This will form a part of the initial pack sent to people enquiring at pre-bid stage. |
Should be renamed to something like "budgeting for open development" |
Rowan |
EUPL licence |
|
|
|
Web browsers |
Focus on how a huge number of browsers all use the same open source core |
|
|
What is the open invention network |
Extract info on OIN from OINevent.xml |
|
(was Ross) |
Evaluation of sustainability models |
Based on All Hands paper |
|
? |
Extracting generic text and advice from the 7 sustainability case studies |
|
|
? |
An overview of commonly found open development tools |
Needs more flesh on the bones |
|
? |
How to make and submit a patch |
ET has completed first edit; more content needed |
|
ET? |
Open source in your IT strategy |
Extracting key points from mindmap |
|
Rowan |
|
Needs more content |
|
ET? |
Roles in open source |
Extracting text from governance documents and Engaging/Getting involved |
Created in wiki but needs fleshing out |
? |
A guide to best practice in engaging with open source projects |
ET to finish 1st stage, then content needed |
|
? |
|
ET to finish 1st stage, then content needed |
|
Ross |
Sahana |
|
Content needed |
Ross |
Additional consultancy services OSS Watch can provide |
|
|
Ross |
Importance of open standards for interoperability |
|
|
Steve |
Case Study: in-folio server 'appliance' |
Supplied by Sirius Has fully open source stack and used in 44 specialist colleges |
EA's team also working on it. Lots of demand for in-Folio but not yet sustainable. Ming-Xien and Kelly at Sirius |
4. Workflow
We have simplified the workflow so that the two content editors can work in a more coordinated way. These are the rules:
- Each team member has one and only one document allocated
- Each team member has an allocated 'next document' - known as a pending document
- Anyone can add to the proposed documents list (potential author need not be identified)
At each review day (ie monthly) we discuss:
- Progress of each allocated doc
- For anyone who has published a doc since the last review meeting we move the pending doc to the allocated doc and agree a due date. We also allocate a new pending doc from the proposed docs list
- Anyone can make a case for swapping their current pending doc with a doc from the proposed list - will be agreed or not by content editors
- Anyone can make a case for swapping another team member's pending doc with a doc from the proposed list (this may be due to feedback/request from a third party or dependency on something they are doing) - will be agreed or not by content editors
Ideally, a document should be developed in the wiki. Deal directly with Elizabeth, who will help you get it to a stage where it is ready to be considered as a briefing note. Since all documents should be seen by a content editor before being considered ready to become a briefing note we no longer need to worry about whether a document is nominated, a candidate etc.

