---
# System prepended metadata

title: Minutes of ORSO meeting on 19 Dec 2130

---

# Minutes of ORSO meeting on 19 Dec 2130

Present: Andrew Nelson, Jochen Stahn, Andrew McCluskey, Tom Arnold, Brian Maranville, Max Skoda.

1. We're going to keep minutes in HackMD in the future. It has collaborative editing to enable to make notes in realtime. We'll upload minutes to Github as Markdown afterwards.

ACTION: Andrew Nelson to start this going. Tom Arnold is going to create the agenda.

2. Next meeting on 20th Feb at 1030 UK time.

3. Started off with discussion about Jochen's [todo discussion points on orsopy](https://www.reflectometry.org/file_format/todo). 

- The first point was to decide on how releases for orsopy get made. Max Skoda/Christy have created guidelines for interaction with ORSO and how decisions get made. Do we wait for an AGM, or can we make decisions on a more granular basis (e.g. by the chairs/developers/etc). AMC pointed out there was a difference between the file-format definition and orsopy. JS mentioned that @aglavic had created a feature branch for model definition, who makes the decision to merge this.
 > [name=Andrew McCluskey] perhaps the orsopy implementation should come after the file specification?.

 > [name=Andrew Nelson] If we wait for an annual meeting the development pace would be very slow
- Perhaps we have a poll for when the minor release/feature branch merge occurs.
- Conclusion: minor releases can get decided by the file format working group (containing a large proportion of the orsopy developer group), major releases (e.g. that affect back compatibility) get decided in the AGM or an online vote in between meetings.

4. Intervening discussion on ORSO statutes document prepared by Max Skoda.

5. Discussion on use of orsopy for non-ort files. Yes we can use orsopy to read non-ort files (devs to decide implementation), but the initial header line would have to be changed.
- Non-ort files are any file that has the same general structure as an ort file (i.e. the hashed header (lines prefixed by #) and columnar data).

6. Standardised optional column descriptions. A good thing for things like "incident_angle" (but what precisely do we call that *alpha_i*, *omega*, *incident_angle*, etc).

7. Discussion on how we approach X-ray equipment manufacturers to use the ort format. 
 - they already have a well developed format. What is the value proposition for them using the format?
 - > [name=MS] Perhaps we should have a converter to swap from X-ray file (xrdml/rasx) to ort?
 - should we contact a manufacturer? Seems negligent not to do so. It was suggested that Christy would be a good person to do that. Max will talk to Christy.
 - 

8. Discussion on how to include uncertainties on quantities mentioned in the header.

