- 1 Steering group meeting 2016-04-04, Stockholm, Arlanda, SkyCity
- 1.1 Time
- 1.2 Location
- 1.3 Attendees
- 1.4 Invited but could not attend
- 1.5 Agenda
- 1.6 Reimbursement
- 1.7 Meeting minutes
- 1.7.1 Discussing the project directive
- 1.7.2 Discussing the collaboration agreement
- 1.7.3 Formal approval of the project directive
- 1.7.4 SGAS involvement
- 1.7.5 Budget concerns
- 1.7.6 Project vision and scope
- 1.7.7 Openness and taking minutes
- 1.7.8 Project start date
- 1.7.9 General discussion
- 1.7.10 National provider perspective
- 1.7.11 Next meeting
- 1.7.12 TODO
- 1.7.13 Important dates
Steering group meeting 2016-04-04, Stockholm, Arlanda, SkyCity
- We start at 9:30 and we close at 15:30.
- Radisson Blu SkyCity Airport Conference Arlanda Sweden (Skycity is between Terminal 4 and Terminal 5)
- Address of the location: Pelargången 1 – S-19045 – Arlanda – Sweden – Phone +46 (8 ) 50674000
We have a conference room booked and lunch and coffee will be served. Eduroam WiFi is available.
- Michaela Barth (NeIC, Chair)
- Gerd Behrmann (NeIC, Technical Advisor)
- Martti Louhivuori (CSC)
- Lene Krøl Andersen (DeIC)
- Hans A Eide (USIT, UiO)
- Radovan Bast (UiT, PM)
Invited but could not attend
- Rossen Apostolov (SNIC)
- Presentation of the project directive
- Presentation of the collaboration agreement including terms of reference for the steering group
- Formal approval of the project directive
- Discussion on policy and openness about documents
- Visions and plans of the project leader
- Scope of the project and project plan
- Decision on the start date and kickoff date of the project
- Staffing of the project team
- Discussion on reference group
- Involvement with SGAS project
- Infrastructure commitments and presentation of national status and intended national inputs
- Next meetings
These meeting minutes have been approved by all steering group members present at the meeting.
Discussing the project directive
- Mentioned relevant "spaghetti-code" article from The Economist: http://www.economist.com/news/science-and-technology/21695377-professors-unprofessional-programs-have-created-new-profession-more?frsc=dg%7Ca
Summary: Michaela gave a project directive walk-through.
Discussing the collaboration agreement
- Involvement of Iceland: The delivery of this project should also be available to groups in Iceland.
- Point 3.4: Lene asked what would happen in this scenario in practice. Discussion: Such a scenario requires early reaction. In case somebody from another country would be ready to fill the gap, one could adapt the distribution but in practice this can be tricky. Milestones will be part of the project plan where the staff and progress can be monitored and checked.
- Point 3.5: Partners should send the bill to NeIC every 3 months.
- Point 4.1: Mainly to protect the employee so that she/he does not have to change her/his work contract.
- Point 5.1: To be ready in 6 months from start of Radovan's employment (in other words before 2016-08-01).
- Point 5.2: Smart to sync quarterly reports with steering group meeting.
- Point 5.3: The code that this project will create will be open but we will not enforce OSS development for the projects benefiting from CodeRefinery.
- Point 6.1: Liability is between provider and third party, not between NeIC and third party.
Formal approval of the project directive
Decision: Project directive approved, project period and FTE table needs to be adjusted.
Current budget proposal assumed that SGAS maintenance being part of this project and being executed in Sweden. Now it looks like that SGAS will likely be maintained from within CSC in the future.
SGAS: originally "Swedish grid accounting system", built for internal use in Sweden. NT-1 is using SGAS, SUPR (Sweden) is using SGAS. used as well in Norway, Finland and Iceland
Effort on SGAS is spread out. There used to be a collaboration agreement for an SGAS maintenance and development project (0,5 FTE per year until October 2015). Formally there is currently nobody who would be responsible to fix a critical bug today.
The group discussed that there is risk that it might shift away focus from scientific codes, however the infrastructure part will be very generic to both scientific and generic software, and it will be good if SGAS is a beneficiary of this project.
The group voiced some concern that the SGAS maintenance activity report will be reported to and evaluated by the SG and thereby this SG group will become responsible for the maintenance of the SGAS project. "We will not use SGAS but we will govern it over the time of this project." How can we define milestones/metrics? Is it more a SLA?
Decision: The responsibility of the project with regards to SGAS is the migration of the SGAS code-base to the CodeRefinery infrastructure and successful application of the CodeRefinery services and tools to further the development and maintenance of the SGAS software. The project assumes no responsibility for operating SGAS services and infrastructure.
- Gerd: Is infrastructure maintenance/operation part of the FTE budget? The team might not be able to guarantee this.
- Hans: Low-level provisioning of infrastructure is probably not done by the project team.
- Gerd: If we want groups to migrate their projects we need to be able to guarantee uptime/response time.
Continuity should already be discussed now. After the start-up effort should be mainly community driven, but some basic functionality ( 1 person working 20-25% (backups, hardware update) + 5000 NOK/yr for hardware (VM + storage for coderepo)) should live on.
Decisions: Budget needs to be corrected for SGAS involvement. Verify the budget in the collaboration agreement. Currently sums up to 4.5 FTE but does not seem to include Radovan's time.
Recommendation: The SG recomends that it would be good to have a long-time commitment.
Project vision and scope
- Source code repository (GitLab)
- Code review and issue tracking
- Continuous integration server
- Source code and binary distribution for closed codes
- Training and documentation
- Training events
- Best practices guides
- Training material
- Community and partnerships
- Software carpentry
- Pooling of competencies
- Visibility at conferences
- Blog and Twitter
- We need to plan for the time after the 2 years period.
- It is worth considering the option of paying for hosting (e.g. githost.io) instead of hosting ourselves.
- Consider possibility distributing code in a container
- Concern: source code and binary distribution platform perhaps too optimistic to conclude in time?
- Will teaching be free for students?
- CI service stands out as the most expensive one. How about eligibility?
- We need to implement QA to avoid bias in documentation and teaching. For this engage communities, get measurable feedback, metrics, track feedback, measure improvements.
Openness and taking minutes
Decisions: SG meeting minutes will be put on public wiki right away, with preamble “not approved”/”approved”. Project group internal discussions should be on internal wiki. For Approachability: an agreement was reached that name, institution, and email address or alternatively home page URL can be placed online. SG members should be invited to the coderefinery slack channel
Project start date
Project start date set to 2016-09-01 over two years. Project kick-off Sep 5 or at NORDUnet Conference 2016 later in September just for the staff.
- At NeIC conference give an advertising talk and workshop. Good platform could be the side meetings of NORDUnet conference, Helsinki, September. Also team members could be present at the same time.
- Another good platform could be DeIC e-science seminars, 1 meeting a year at different universities.
- Centralised hosting requires long-term assurance and possibly dedicated budget. Martti: If we go for centralized solution we should consider negotiating a commitment beyond the project scope. SG needs to have an idea of the costs. Martti: would be more comfortable promoting an external service rather than promoting a service without continuity. Service would mainly involve upgrades and backups.
- Lene: What are the user communities? Radovan: Groups who are on GitHub will probably benefit from training. Then user groups who do not want to use GitHub because of money or openness. Then there are groups who do not know Git/GitHub/GitLab. They will benefit at different levels.
- No lock-in in any infrastructure solution to be able to migrate.
- Martti: Suggestion for a Nordic test quota so that you can log in to a remote server and test whether the software builds. Gerd: might be more interesting to test on different OSs (VMs) rather than different hardwares otherwise the scope risks to go beyond the scope of this project.
- Lene: should not be a one-person teaching operation but rather use pooling of teachers.
- Continuity of the project can be problematic.
- Timeline should be start with best practices, then services need to be up and running, after that recruit groups and train.
- Topic is not a hard sell.
- Allow and encourage reuse and adaptation of course material to ensure continuity also in training.
- When positions are shared among several people: more competence and teaching load can be shared.
- Reference group: representatives from different use cases.
- Identify use cases as ambassadors who will serve as catalysts in their community.
- Provide contacts to specialists who can then help further to optimize/streamline.
- Martti: keep in mind that if it becomes successful that there are more requests than people. How do we then decide who to give course to and who not?
- Lene: courses could be videotaped. Suggested to also provide webinars.
- Edit short youtube videos out of it. Developing MOOC takes a lot of time. Short video guides are possibly much better than videotaped entire lectures.
- Need to define focus points: groups who are already coding. It's about software development tools. Probably not for complete beginners.
- Gerd: project has analogy with writing a novel. It's not about learning to read and write, it is about learning how to organize the writing and publishing effort.
- Blog posts or mailing list newsletter: blog post is easier to disseminate.
- Hans: What are climate people working with? We should get in contact.
- Martti: What is a use case? Focus group for training and follow-up. Targetted group for training.
- Integrate this into PhD level curriculum for students who code. Raise awareness. Disseminate information. Make people aware that it exists. It's about attracting projects and getting them on board.
- Suggestion: Schedule kick-off meeting next to NORDUnet Conference 2016 in Helsinki.
National provider perspective
What national providers would like to see coming out in this project:
CSC: Involve one of our in-house software development groups as an example. Interest in cross-borders limited compute quota for testing purposes to cross-test/build their codes, in particular beneficial for groups developing HPC codes.
Sigma2: Somebody from the metacenter should join the project team. Framework that would be used and marketed nationally. Good case for sharing resources.
DeIC: Works as ambassador. What would benefit DeIC is the ability to point users at a platform. Working a lot with humanities group who is finding their way into the computational science. Interest in staff exchange and mobility plans. E-science integration initiatives. Courses are not provided directly by DeIC but aggregated and coordinated, pointed to. We need to be more specific about the competences which are needed in the person joining. DeIC gives away some CPU hours for new research projects to get on HPC platform. This is then a good starting list. Suggestion: Identify some primary use cases where we work a little bit harder so that others follow.
Decision: Next meeting scheduled for June 14 at Oslo Gardermoen.
- Adapt the project period in the collaboration agreement
- Project plan needs to be ready and approved before 2016-08-01 (6 months from start of Radovan's employment).
- Remove reference to cloud project from project directive as included in the collaboration agreement (copy-paste error).
- Budget needs to be corrected for SGAS involvement.
- Verify the budget in the collaboration agreement. Currently sums up to 4.5 FTE but does not seem to include Radovan's time.
- Radovan needs to create a clear list of competencies for the people he would like to work with.
- Identify some primary use cases where we work a little bit harder so that other projects follow.
- We need to identify use cases in different areas. Steering group will decide on the primary use cases.
- Get an idea of the costs for paid hosting.
- Clearly formulate the user communities.
- On the website list the training events and resources that are related: SWC, other platforms, PRACE.
- Project plan needs to be in place before mid-summer. It can be worked out even without the project team in place. Providers would like to have a date to set up a budget. We want names before summer (June 1st). Start working after summer (after August).
- Radovan needs to provide skills/profile for people. Clear list of what we need and what we want.
- Staffing process in Denmark: Open call going out to all universities.
- Draft for project plan before April 25. LaTeX is OK but also provide pdf.
- Project kick-off Sep 5 or at NORDUnet Conference 2016 later in September just for the staff.
- Names are appointed by Jun 1. Names go into the project plan with some description of the people.
- Official start of the project Sep 1.