Has anyone else given any thought to replacing any of the Javarosa logic with standard XML utility libraries, and if so, did you already rule anything out as being an option?
I'm aware of some conversation on Slack and on GitHub over the last year. For example, https://github.com/opendatakit/javarosa/issues/17 and @dcbriccetti may remember more. The conclusion has generally been that we should make sure to have clear user-serving goals before going down that kind of path. For example, if it would help significantly with performance it might be worth it. This would require beefing up the test suite significantly.
Is there a process in place to enumerate and triage smaller stylistic fixes like the above? It seems like filing a github issue for each would be excessive, is there a better way to contribute these small changes?
I'm personally very happy with small, beginner-friendly issues being filed. In our last @TAB call we talked about formalizing guidelines and processes that have emerged organically. How granular of issues to keep and whether to encourage or discourage refactor-only work of different sizes will be areas we discuss I imagine.
Is there a process in place to undertake any larger refactoring tasks, and if so, are there any that are on the radar currently?
Again, no formal process but it's the kind of thing that the @TAB will eventually produce proposed guidelines for. So far the majority of refactoring done has been in service of immediate user goals. The process in the past year has been to share a proposed approach on a GitHub issue, get some feedback, share an in-progress pull request, get more feedback. Recent examples include
- @jknightco reworking the geo widgets to fix a whole host of issues described at Collect geotrace and geoshape improvements. While doing this he is using modern Android architecture strategies. This is ongoing work -- feedback is being given at https://github.com/opendatakit/collect/pull/1785
- @ggalmazor separating CLI and GUI logic in Briefcase -- https://github.com/opendatakit/briefcase/pull/252. This is to separate the CLI from the logging infrastructure so users can properly see logs and still get command-line feedback. It's also to capture redundancy in business logic that will be changing.