Thanks for sharing your perspective. I understand the point of formalizing contributions but wish to challenge the need to do so for every type of contribution.
For instance changes that have low impact production (eg. clarifying documentation) are subject to the same process as high impact changes. We are experimenting with an idea where depending on configuration + heuristics (file, author, semantics of change) the formal review is skipped, recommended or enforced. Alternatively, permit deployment to staging environments without sign off.
What we aim to achieve with the real-time design is create value that would not otherwise be possible. For example, making use of CI much more frequently. I have in the past made and pushed throwaway commits just to trigger CI and get feedback sooner.
We have been using Sturdy in it's own development over the past 9 months. I'd say the workflow doesn't quite resemble pair programming. We check each other's work-in-progress occasionally and give code suggestions/comments whenever we can be helpful to one another.
> We have been using Sturdy in it's own development
I'm wondering, if one person has some edits in progress (which won't compile), and another person wants to compile and run the app, then, does s/he need to wait for the first one to be done editing?
Nope! Sturdy never syncs edits from one computer to another directly. Our analogy with Google Docs might be falling apart a bit here.
We're working in separate workspaces (which you could equate to a branch), and are syncing and sharing the workspaces only when the code is in a good state.
Ok, and, a good state -- I'm thinking that means when there are no syntax errors -- I suppose that generally it's not feasible to compile and run all tests.
One way to use Sturdy, that looks the most interesting to me currently, could be to onboard new team members -- maybe fixing some problem in their first contributions, while they see the fixes happen real time and can ask questions
What we aim to achieve with the real-time design is create value that would not otherwise be possible. For example, making use of CI much more frequently. I have in the past made and pushed throwaway commits just to trigger CI and get feedback sooner.
We have been using Sturdy in it's own development over the past 9 months. I'd say the workflow doesn't quite resemble pair programming. We check each other's work-in-progress occasionally and give code suggestions/comments whenever we can be helpful to one another.