zizroc/villager

Decide on Developer Habits

Closed this issue · 3 comments

I'm guilty of being a cowboy coder; working on a ranch long enough might do that to you ;)

I'm sure @zizroc is at this point, tired of my "Oh I literally just pushed 2 minutes ago rebase", "Oh yeah yesterday I made that change, you'll have to pull", "Bro it's going to be a j4ck3d merge when you get the latest changes", etc comments. Continuing on like this would be madness, and it would bee better to keep everyone in the loop before new code is added. This will slow things down which at this point should be okay. We have the base state machine and now we're adding extensions to it (like trade).

I hate too much structure and don't want to opt for a full development process because it makes software a dead black and white dismal thing (personal opinion).

  1. All code is added through a pull request and approved by 2 people
    This means that most of us will have seen the new changes and know that we need to update our branches. It also forces us to keep up with the codebase. Over time we will have seen and judged just about every line that goes in.

  2. Pull requests are linked to issues
    When there's a bug, it's good to get context as to where it came from (so that the fix doesn't break anything). It's also nice just for record keeping (ie why did we pick license X?). I'm pretty relaxed on this one, but think that it might be a good idea.

What do all think?

Re. 1. Yes, concur.

Re. 2. I see this for bugs. But what about upgrades? (I.e., very small code changes that are unlikely to break anything or result in bugs). Do those not usually become pull requests?

I'm totally fine with relaxing point 2. Everything should go through a pull request so that the continuous integration system (Travis) is able to verify that the package still builds, unit tests didn't break, etc.

Note on point 1: Time might be an issue, so I think if the PR is in for more than something like a week and it has at least one approval, it should get merged (we do this in one of my current projects). After a week, it gets hard to add features because of the potential merge conflicts, so to mediate giving an expiration should help.

More than less done