---
# System prepended metadata

title: Open Source Service Area
tags: [Service Area, Open Source]

---

* Attendees: 
	* Nick
	* Aoife 
	* David LJ

## Questions
1. What should the service area (SA) do?
2. Who is/was working in the SA in the past? 
3. FTE Allocation? 
    - Really Determines how much effort REG feels should be dedicated! So would be great to have a general idea of. 
4. [name=Nick] Clarify with May where (if any) the line is between REG and
   Turing in terms of service areas (may also require a wider team discussion)

## Ideas 
1. [name=Nick] Drop in sessions
    - [name=Aoife] Wasn't there talk about REG doing this in general. Perhaps we could latch onto this, or if it hasn't started we can push it along
    - Advertise to the new #reg slack channel! 
3. [name=Nick] Liaise with TPS
    - [name=Aoife] I'm so down for this, been wanting to chat with them more!
5. [name=Nick] Organise sessions to contribute to open source packages we use
6. Organising hackathons [name=Aoife], not sure if this is what Nick means above, so sorry if I've stolen it and just reworded here.
    - Could tie into things like force multiplier? 
        - e.g., "We have this project, it's untested and not well documented, let's throw RSEs at it for an afternoon and make the repo accessible"
7. Regularly review existing projects  
    - Maybe would be useful to write scripts to routinely scan Turing GitHub repo's for valid licences 
    - Could produce lists of private projects and then manually inspect to see if worth reaching out to owners to help them make OS
    - Watch for projects with open issues unanswered? 
        - This is more of a shot in the dark, but I wonder if it would be worth catching projects with stale issues (looks bad if external people ask Qs or have problems and no one from Turing responds to them on public repos) 
8. Ensure that REG repos have `someone` watching them? 
    - Basically try to make sure we don't have orphaned repos
    - Could make lists of active repos and ask the team to 'claim' them? 
        - If we did this regularly then it could be a straight-forward monthly thing of quickly asking the team
9. Ensuring there's sufficient documentation for new-starters to make sure they fully understand REG's commitment to OS
10. Similarly, ensure there is guidance and recommendations in the REG handbook (chat with the people in charge of documentation SA?)
11. Hacktoberfest! 
12. Don't forget about the Turing Way! 
13. JOSS reviewing
## Next steps 


- [name=Nick] check with May, Evelina, James G about making official allocation.

## Misc thoughts 

- Are there alternatives to github where it would be good to promote and think about how 'open' we make our work
    - For example there's things like figshare 
- [name=David] How do TPS interact with internal Turing 
    - TPS coffees and community managers + RAMs?
- [name=David] RFC repos: https://github.com/alan-turing-institute/Hut23/tree/master/rfc and the "new REG repo template RFC": https://github.com/alan-turing-institute/Hut23/blob/master/rfc/rfc/0006-github_templates.md