Overview of our support plan for projects we engage with - linked to from the Welcome Pack
OSS Watch engages with and support projects through a clearly defined process detailed in a support plan. This document presents an overview of the OSS Watch support plan for the use of the projects we advise.
- telephone or email directly or via rt queue
- contact at events organized or attended by OSS Watch staff
- approach as part of funding application process
[TO DO - expand]
The welcome pack is an online resource we point projects to after making first contact. The text consists of an intro to OSS Watch project engagement and a list of relevant OSS Watch docs:
- Description of OSS Watch service + links to website, newsletter, news feeds, blog, twitter, video channel
- Overview of Support Plan as project engagement process (incl description of Simal and Openness Rating)
- Request for projects to enter DOAP data in Simal and suggestion to perform Openness Rating Lite
- Reading list with paras introducing each doc:
- * What is open source software
- * Avoiding abandon-ware: getting to grips with the open development method
- * A guide to participating in an open source software community
- * Sustainable open source
- * Governance models
OSS Watch maintains a publicly accessible catalogue of supported projects. This catalogue is used by OSS Watch staff to keep track of the progress of projects we support, and by the projects themselves to discover related projects. The software behind the catalogue (Simal) is itself an open source project. Information about a project can be entered in an on-line form to create a uniquely assigned project file (description of a project, or DOAP file). A DOAP file contains basic information about a project, such as description, aims and objectives, main contact points, IPR management and licensing terms, community development tools and activities. The DOAP file is used to keep OSS Watch up to date with the development of the project, and to ensure projects get the maximum exposure to and from OSS Watch services.
Openness rating evaluation
Openness Rating is an evaluation tool for assessing the degree of openness of a project. This is part of the Software Sustainability Maturity Model (SSMM) which is being developed by OSS Watch. This online form and results page are used as part of our internal review process. We also encourage projects to perform self-evaluations using a lite version of the Openness Rating tool as a good learning activity and a resource for us to use in consultations.
The first consultation, also known as the planning meeting, will be preferably face to face in a location chosen by the project. Alternatively an online call meeting will be set up. We expect at least the project lead and the project coordinator to attend. The 1st consultation should take place as quickly as possible after contacting a project. The planning meeting is designed to ensure that OSS Watch understands the project and the project understands how OSS Watch can support the project. At the end of this meeting OSS Watch should have a clear understanding of what kind of assistance the project is likely to need.
Prior to the first consultation the project will be emailed a welcome pack containing information about OSS Watch and about the main open source issues that will be discussed in the meeting. The project will need to fill in two online forms in preparation for the meeting: a DOAP file describing the main features of the project, and an openness rating form aimed to assess the project's attitude to openness.
If the project has created a DOAP file OSS Watch staff will ensure that the project is visible in the project directory and will review the entries with those present. The meeting then progresses onto discussing issues covered in the openness rating evaluation. The aim is to find out more about the project that is not public knowledge, such as IPR management and intended exit strategies. Further issues will then be touched upon, such as the project's motivations with respect to open sourcing the solution, plans (if any) with respect to sustaining the software development, or any concerns or questions the project team may have.
Actions and the date of the next meeting will be agreed upon and recorded in an action plan immediately after the consultation.
Dump text from email:
Before the initial consultation project owners perform an internal review, which involves doing some basic research about the project. The docs in the specific section of the welcome pack are chosen according to this provisional knowledge (e.g. I will include 'Open Source and Research Infrastructure' if the main focus of the project is research, but I won't if the project is of a more technical nature). Of course, after the consultation, when we have a clearer idea of the support required, more links can be sent to the project, but these are different from what we call the welcome pack.
>>> >>> How about this simple process: >>> >>> >>> >>> * 14 days before consultation: project owner emails EB list of specific >>> >>> docs relevant to project (other than those on the generic list) >>> >>> >>> >>> * 7 days before consultation: EB writes brief intros for these docs, >>> >>> adds them + links to pack template, emails pack to project owner >>> >>> >>> >>> * 5 days before consultation: project owner emails pack to project team >>> >>> >>> >>> >>> >>> If you are happy with this process I'll add it to the support plan. >> >> >> >> I'm confused. >> >> >> >> How do we know what the specific support items are *before* we have done >> >> the consultation? > > > > > > Before the initial consultation project owners perform an internal > > review, which involves doing some basic research about the project. Of course they do, that makes sense.
In that case my response is that the turnaround on this is way to long and it is too time dependent.
That is "14 days before" implies the owner has to do it on a specific date when actually all we care about is that it gets done. I therefore suggest that we notify Elena as soon as we have identified the items of interest (i.e. in the review report).
Rather than fixed days for turnaround I suggest you decide what is realistic and define it as something like "generic pack items are sent within 3 working days of initial contact and specific pack items are sent within 10 working days of initial contact."
... and from Support Plan doc:
A meeting with the project, usually F2F but might be online. The first consultation is known as the planning meeting and a mid term review is usually scheduled. Funded projects will also have a wrap up after completion. All meetings cover ground agreed by both parties. Next actions are agreed and we recorded them in the Action Plan in the 'Decide Support' process which happen immediately after the consultation.
Prior to 1st consultation we need to obtain * motivations with respect to open sourcing the solution. * plans (if any) with respect to sustaining the software development * the biggest questions/concerns they have * their Openness Rating The Planning Meeting is designed to ensure that OSS Watch understands the project and the project understands what OSS Watch provides. At the end of this meeting OSS Watch should have a clear understanding of what kind of assistance is likely to be needed by this project.
All projects will, wherever possible, be visited by one or more OSS Watch team member. This first meeting willbe at a location chosen by the project and should be attended by, at a minimum, the project lead and the project coordinator. The purpose of the initial meeting is to reiterate the goals of OSS Watch and to highlight ways in which we are available to help typical Higher and Further Education projects. It will therefore commence with a short (15 minutes) presentation on OSS Watch.
If the project has created and hosted a DOAP file the team will ensure that the project is visible in the OSS Watch project directory and will review the entries with those present. If the project has not yet created a DOAP file a short (10 minute) presentation on how to create and manage one will be made and a task will be recorded to create one.
The meeting then progresses onto completing the project activity record. This contains information about the project that is not public knowledge, such as IPR management measures, and intended exit strategies for the project. This exercise should take approx. 40 minutes.
At this point we move on to the main purpose of the meeting. In the case of a meeting requested by the project there will be a specific point that is to be discussed. In the case of the meeting being instigated by OSS Watch this will be a more general discussion about the level of project teams understanding of Open Source as it relates to this project.
The final task for this meeting is to summarise any specific issues that the project would like to address at some point in the future. These items are agreed upon by both the OSS Watch and project team members and will generate actions for the project and/or the OSS Watch team.
One specific action that will be scheduled for all projects that agree, is to schedule a mid term review of the project.
Mid Term Review
This review is a chance for OSS Watch to update its records concerning the project and for the project to identify any specific issues it may have uncovered with respect to its use and/or development of open source software. During the review the projects DOAP file will be examined to ensure it is current and valid, any outstanding actions shown in the projects activity review will be flagged and the project will be given the opportunity to provide feedback about OSS Watch and its support package. This review will usually be performed via email. However, at the projects request member of the OSS Watch team will be available to visit a site nominate by the project itself.
Approximately one month from the end of a projects funding cycle OSS Watch will contact the project to offer any final �wrap up� assistance that may be required. In particular, this communication will focus on assisting with any further funding proposals or realising one of the defined exit strategies.
This final communication will also request that the project completes an OSS Watch evaluation. This evaluation is a short document allowing the project to provide valuable feedback as to how effective OSS Watch have been in supporting the project team and to offer any constructive criticism they have.