Good news about credentials, @W_Brunette! Is there a spreadsheet of credential types (not actual credentials!) and who has access to each that could be publicly shared? Knowing for sure that there is redundancy for every credential type would certainly make me sleep better at night. Having it be public would help make sure the information is broadly available in case of any problems and would help make it clear where there could be opportunities for community members to increase redundancy. I think it would be a good first step towards shared credential infrastructure.
@Souirji_Abdelghani Thanks for bringing up this important question about release pace. It's something we've discussed in the latest ODK 1 Developer Calls. There are tradeoffs associated with any release schedule and so far the sense has been that regular releases has been overall positive for the following reasons:
- Crashes have gone down significantly on Collect. There aren't yet analytics on the other tools but issues that were brought up have been fixed in a timely manner.
- Contributors know that their work will be available soon. If a change isn't ready, we can wait until the next release knowing that it isn't too far in the future. In particular, we never need to rush to get a change into a particular release because we know another one is coming soon.
- It's easier to fix issues in code that has just been integrated rather than to address them months later.
- We've developed a good culture of considering risk for each change that gets proposed. You can see this on every pull request and in conversations on the developer Slack.
- Only having one active development branch to manage lowers overhead significantly. This is important because the developer community continues to be small relative to the user community.
- User feedback has overall been positive as measured by positive comments on public channels, user interviews and word of mouth.
If there have been problems with the releases, it's really important that they are highlighted immediately. @Souirji_Abdelghani if you have observed some, please take a moment to write them up for the support category so that they can be addressed. The intent has been and continues to be that changes released do not require retraining. This has been verified informally with various groups that use ODK at scale but if it's something you are concerned about, please make sure to try out pre-releases and ask for changes as needed.
All that said, while I do think this process has been effective for incremental changes, as more sweeping changes are considered we will need to look to different processes including things like using feature switches and putting out longer-running betas. Any suggestions for those would be much appreciated so that we are as well-prepared as we can be to make bold changes in positive ways.
I have to admit my personal experience with LTS builds has not been positive so I'm wary of them. @Souirji_Abdelghani if you have a good process for validating and maintaining LTS builds, please consider writing up a proposal post in this thread and/or linking to other process documents you find useful. In particular, all builds are available on the website and continue to be supported here on the forum, what processes would make the LTS builds different? What do you imagine your role could be in making this happen? Could you maintain LTS branches and get the ready for release? Help get user feedback and testing?