We would like to value our forms in scientist and/or nature management journals (mainly french) , as we do with the protocols they apply, and the standardized datasets we produce.
In other words we would like to value it as a product of our work.
Has anyone already written such an article ? If you did, how did you describe your form ?
And could you share some references ?
Is there any standard to describe field tools ?
Some @TAB members are scientist and may have some answers, but so do mny others in this large community.
Not something I have done before, but definitely of interest and on my (long) todo list. Maybe something to explore further together with others as part of the ODK summit? (@chrissyhroberts? @aurdipas?)
From what I had rapidly browsed, it seems to me that there are two main publication targets:
a methodological paper that describes the tool development approach
a data paper that describes the standardised dataset(s) as well as the main features of the data collection tool(s) that led to data acquisition
If you have not already spotted them, CIRAD has developed some excellent online resources (in French ) on data papers:
Speaking from personal experience, publishing methods papers is very hard work and can be pretty dispiriting as there's (a) a lack of journals which specialise in this kind of work, (b) very few qualified/specialised reviewers and (c) sadly limited recognition of the importance of methodology papers in academia.
There's definitely a lot of work being duplicated (the WHO verbal autopsy XLSforms have been made by at least four different groups that I know of, mine included) and having some kind of semi-curated, highly structured and 'officially recognised' repository for useful XLSForm code/forms/blocks/functions/regex/methods etc would be really valuable. We have discussed this at @TAB meetings in the past, but haven't progressed much towards a coherent solution.
Personally I think that this shouldn't be limited to forms, but should include useful protocols that often find their way on to the showcase. i.e. things like Python Notebooks, R Markdown, Plugins, modifications, documentation, etc. Some coherent DOI/versioning could also be valuable for legacy interoperability, scientific record, permanence etc.
As a big ODK user/deployer/shepherd who has less background in the core software dev/ops stuff, this is the kind of thing that I am really keen to pursue with others coming from that side of the ODK experience. I agree that we should have a substantial breakout group discussion about this at the convening and should aim for a proposal/outline design for a form/methods sharing solution as a deliverable of the meeting.
This also feels very close to educational & training work so I would be interested in hearing @janna's perspective.