Hooooray! Thanks all for a great hackathon! We're well on our way to create something really special. We got a lot of good work done and we've defined a bunch of TODOs to move ahead with.
See our TODO list here: https://github.com/theborderland/realities/projects/2
From now on, we should move forward with branches and pull-requests. With regard to managing the project and reviewing code, we'll need to start following some set methods for how we work. This is definitely not my area of expertise, but from what I've gathered both @matthewparsons and @erikfrisk have that sort of experience and they have both started proposing some best practices. We'll fall into our roles as we move forward and keep using Loomio to make the big decisions and plan ahead.
We should focus on getting something up that our Reality Guides can start playing around with. Let's talk about how to get there. When we ended the hackathon, most people expressed interest to keep going in next few weeks and months. I certainly am!
So, next steps?
Matthew Parsons Mon 11 Dec 2017 11:27AM
Thanks @hugi and @erikfrisk and everyone else - I really enjoyed working on this, despite being far from the action.
Re. code reviewing - it's just good practice, and with a balanced approach (as Erik mentioned - not too much and not too little time spent) I think it makes for better outcomes.
As for the CI pipeline - when up and running, it's going to be somewhat resilient to breaking: hopefully we'll have good test coverage for the API and the UI components (I would advocate against e2e tests - anyone have an opinion on that?). However, it is the case that we don't want to see any/many direct commits to master - we should be merging everything in from branches. Git workflow is so easy these days there's no reason not to do it. We should really be branching off for each ticket we work on (from the Github project board), no matter how small the task, and even if you don't have your code reviewed and merge it yourself.
I also advocate - as Erik does - in keeping the repo open for devs at the hackathon and in general: process is important, and often learning happens through making mistakes.
Erik Frisk Mon 11 Dec 2017 6:23PM
Completely agree about working on everything in branches. I was bad about that during the hackathon but it's more necessary now that we're more distributed and less synced. I also agree that we can avoid e2e tests for now. It's an ordeal to set up. We can always add them later if we feel the need.
Hugi Ásgeirsson Mon 11 Dec 2017 11:53PM
FYI my days this week are pretty crazy, turns out I’m pitching a project in the Swedish parliament on Thursday... So I won’t be able to formulate an action plan. But if someone else does and starts a proposal on accepting it, I’ll try go get people here to give their thoughts on it so that we can move ahead in sync.
Erik Frisk Tue 12 Dec 2017 1:04AM
Wow! Good luck with the pitch :D My week is messed up too. Flying back to Sweden tomorrow. I hope to be able to continue working on the Authentication this weekend though.
Erik Frisk · Mon 11 Dec 2017 4:01AM
Yes! Thank you all, and especially thank you to Hugi for getting us rolling! :clap:
One question I've run into now as I set up our Auth0 account is which domain we'll use. Who has access to the theborderland.se DNS? I suggest we do realities.theborderland.se for the app and api.realities.theborderland.se for the API.
I don't have a lot of experience managing a repo with a distributed team like ours. My instinct is that we need a code review process of some sort. It should be as light-weight
and natural as possible. If we have too little review we'll be slowed down by inconsistent and perhaps poorly designed code, but if we have too much review we'll be slowed down by the process itself.
We could try this:
People who are familiar with the project, feel confident in their development skills and manage to get some level of trust from the group are given full permissions to the repo and can merge and push code whenever they want. (Anyone who pushes code to the master branch could break the app in production given that we get a CI pipeline going.) As a rule of thumb these people should ask at least one other person from the group to review their code post-merge, but we don't strictly enforce this unless we start running into problems.
N00bs to the project and/or people who are less confident in their development skills contribute code through pull requests. After a new person has made a couple of contributions and earned some level of trust, they can be given permissions to push code themselves. Anyone from the veteran group can review pull requests (providing feedback and gentle direction when needed) and merge them. This way n00bs-to-the-project and less-confident-developers get some help and guidance in familiarising themselves with our design choices and practices before they're given full permissions.
I imagine everyone at the hackathon should be considered a vetaran with full permissions, unless they themselves feel unsure and prefer to contribute through pull requests for a little while first. A clear benefit to submitting a pull request is that you'll get feedback on your code—a potentially great learning experience even if you're a seasoned developer.
No matter what process we choose, it should be reviewed and adapted if it doesn't work for us. Every process is an experiment.
What do y'all think?