Use existing infrastructure whenever possible (e.g. Sage's trac server), and in particular when contributing to existing software.
Use ODK's github organisation for most public ODK specific infrastructure.
Add a post in the news or activities pages of the website or an entry in the events section.
Typically a talk at a conference goes in the activities section while an ODK workshop (or related workshop) goes in the events section.
See our Acknowledgement web page
The Commission attracts our attention to the most common errors identified in cost claims:
For the full version delivered by the Commission, click here
The Université Paris-Sud published an information sheet on openaccess best practices. You can find the information, in French, here.
However an internal process has been set up (cf Data management Plan)
Partners will be following the process explained below. The lead partner of the publication takes responsibility for the openaccess process for peer-reviewed publications.
Partners must be keeping in mind the Commission asks not to accept more than 6 month embargo (to check the publishers’ policies use http://www.sherpa.ac.uk/romeo/)
Partners upload publications on http://arxiv.org/, or on another openaccess platform of their choice
Warn the Coordinator so that they keep list of publication of OpenDreamKit publications updated on the project website
The lead partner of a publication will send to the Project Manager all the data related to the peer-reviewed publication once it is given full openaccess. Data related to a publication are all the data needed to reexamine the research leading to the publication. The Project Manager will publish the data linked to publications on http://zenodo.org/. Thanks to the publications’ DOIs, the data will be linked to publications.
Once publications are published on an openaccess platform and their data published on Zenodo, the OpenAire website will be linkage between them. All OpenDreamKit published work will be present on this webpage: https://www.openaire.eu/search/project?projectId=corda__h2020::1930bdaa9032dd5b34f25841ebf3e8d1
In order for publications and data to appear on this website, one must state when completing forms on the openaccess paltform (such as ArXiv) and Zenodo websites that the concerned work is being financed by Horizon 2020 project number 676541.
The few private discussions (that involve for example nominative information) should occur on the relevant private mailing list (steering committee, coordination team, ...; see our contact web page).
Please make sure any private information is encrypted, especially given that some of us use gmail.
Fine grained public discussions should go on github issues, with notices to the appropriate teams and persons.
When an important such discussion is started, a notice shall be sent to participants@opendreamkit.org.
Design goals:
As much as possible of the discussions is public, centralized, easily searchable, linkable, etc.
People can keep a broad eye view on action happening in other work packages, without being flooded by e-mail / notices.
You can use this repository (or that of the web page when relevant) to collaborate on public documents. There is a subdirectory for each work package.
Private documents can be shared using the private repositories of the relevant body:
Each ODK task and deliverable is modelled by a public github issue. They are accessible from the sidebar of our web page. Furthermore each deliverable is attached to a milestone for tracking its deadline (Month xxx of the project).
The purpose of those issues is:
To keep track of our progress, both for ourselves, but also for outsiders and for our EU reviewers.
To host discussions
A first draft of each issue was created automatically using the metadata produced in Proposal/final.pdata. It should be further edited and maintained. The issue should be assigned to whoever will be leading it, in addition to the work package leader.
By convention, we use the first comment on the issue as a description of that issue (github is missing an explicit notion of issue description). It should contain and be continuously updated with:
todo list, sketch of plan, references to relevant resources on the web, @mentions of people that could/should be involved.
Whenever possible, this includes creating issues/tickets on the tracking systems of the relevant systems.
For examples, see #50, #87, #72.
Alternatively, when natural, the issue can be a brief pointer to an issue of the relevant software where the actual discussion happens. In this case, only ODK specific info (link to task, delivery date, status report, ...) needs to be on the issue.
Edit the github issue description (i.e. its first comment) to give an overview (think abstract of a paper) of the deliverable. This information will be included at the beginning of the report.
What was the original goal.
How it fits within the overall ODK picture.
Where the work started from.
What precisely is the deliverable, and was achieved during the project, clarifying the contribution of the ODK participants and of the community.
A brief view on applications, further outcomes, current activities, future plans.
The distinction between what was done before, for, and after the deliverable should be strictly unambiguous.
This description should be self-contained. Still, it's recommended to enrich it with cross links as appropriate. In particular add links for all issues on the different component trackers (trac, ...) that have been worked on to achieve the deliverable. The link label/context should be explanatory: the reader should not need to follow the link to know what additional information it provides.
If this gets too long (say more than one page), the details can be left to the report itself.
Double check the deliverable metadata is up to date:
A report should be written, in LaTeX, and in WPX/DX.Z/report.tex
, using our
style file. You can initialize
the report file and copy the relevant style files with:
make WPX/DX.Z/report.pdf
Rerunning this command later will update the style files if needed and recompile the report.
See the existing reports for further examples.
The github issue description is semi-automatically included in the report. To fetch it from github, run the following command from ODK's main repository (no worry if this step fails for you; the coordinator will anyway run it before submitting the deliverable):
DIR=WPX/DX.Z rm $DIR/report.pdf $DIR/github-issue-description*; make $DIR/github-issue-description.tex $DIR/report.pdf
(requires PyGithub and PyYAML: pip install PyGithub PyYAML
).
You can then commit the updated github issue description and pdf with:
cp $DIR/report.pdf $DIR/report-final.pdf; git add -f $DIR/github-issue-description $DIR/report-final.pdf; git commit -m "basename $DIR
: updated github issue description and report pdf" $DIR/github-issue-description $DIR/report-final.pdf; cp $DIR/report-final.pdf /tmp
The report shall be self-contained. Indeed, the deliverable will be evaluated based upon its version submitted on the EU portal without retrieving other resources. Links have no legal value, since there is no guarantee that the referenced material will remain unchanged. One may typically want to add relevant material as appendix (e.g. snapshots of software documentation, websites, or other relevant documents); see e.g. WP5/D5.1/report.tex or WP2/D2.1/report.tex.
The use of pictures and other visual material is strongly recommended.
Defining authorship is tricky, as most deliverable involve close collaboration with the community, and the report is often written by a subset of the contributors. Let's use the following simple rule of thumb: the authors of the report should include all persons funded by ODK that contributed non trivially. Not including outsiders in the author list is reasonable, as the report is about the contribution of ODK.
Request early feedback, review, and final proofreading of the report
Plan ahead, as this will take a couple days!
Write a blog post in ODK's news
Send a notice to participants@opendreamkit.org
Go to the root dir of the main OpenDreamKit repository
Edit the Makefile to add the deliverable
Run make to automatically download the github description and build the report
Proofread the pdf
Commit it as report-final.pdf
Add a link to the report in the github description
Submit the PDF on the EU portal:
login
go to My Projects, Manage Project, Continuous Reporting Data, Deliverables.
Uploading a pdf used to fail for me with firefox (Nicolas). A workaround was to wrap the pdf in a zip file.
Close the issue on github
For ODK, but also for all of those that are watching with hope over our shoulders, it's important to write useful reports on our work during the workshops. To be productive, we should write those reports collaboratively and on the fly.
Suggested approach: initialize the report with the list of projects, and put it on a collaborative pad (e.g. hackmd). Then, during each status report, display the report on the screen, and ask everybody to take lives notes both on the plan and what's done, directly in a synthetic project-by-project form. The goal is to have a couple paragraphs per projects, with links to the end results. And an overall debriefing.
The agenda must be
Day 1: test (mock presentation). This should be the exact same setup as on the day of the meeting (day 3). But without the EU reviewers.
Day 2: project meetings
Day 3: official review with
(Project Manager) Send official e-mail invitations 20 days in advance to all the meeting participants, with the agenda. Those e-mails are to be kept for later audits (proving that the attendance was necessary).
(Project Manager) Prepare a signature sheet to collect attendance (to be kept for later audits).
(Project Manager) In the appropriate git repository, prepare for each site, a template file for the progress report, and request all partners to fill in the file in advance.
(Project Manager) Make sure that all the support material (e.g. slides of progress reports, ...) is available in advance (e.g. posted online), linked from the agenda, and read by all participants before the meeting. This way it is sufficient to scan quickly through them during the test, stopping only if some point raises a discussion.
(Project Manager) Set up a pad (e.g. on framapad) or/and a chat room (e.g. gitter or use the one in framapad) for collaborative editing of the minutes during the meeting. Initialize the pad with the agenda, and links to all supporting material. After the meeting, move the content of the pad into a file in the relevant git repository for later editing. Whenever appropriate, make this file accessible online.
Remote participation: For meetings of 4-5 people, RPC-based video conferences as above can possibly do the job. For a larger number of people, this does not seem to scale. Here are some recommendations:
Request all participants to have a wired access (not wifi).
Plan for a backup solution so that participants can join by plain phone.
Renater's Rendez Vous might be a good option as it is supposed to provide a bridge with phone lines. However, at this point (February 2016), only the latest development version of firefox is supported.
Explore webcast solutions as an alternative to peer-to-peer video conference, so that at least remote participants can follow what's going on.