Project management changes

[robn]

Hi all,

We're making some changes to the way the project is managed, with a view to opening up development to the community more and removing some of the bottlenecks to getting changes into the codebase. Here's the details.

1. Access to push to the master git repository is now open to everyone. If you want access, you need only ask. There's a small vetting process which mostly consists of determining if you can be trusted to take good care o[f the project and not screw anything up.

2. The pull request and code review process still exists, but we're not placing as much emphasis on it. New contributors that don't have git access yet will need to go through it as before, but the bar has been significantly lowered. Anyone can review, and anyone with commit access can merge it. Getting a PR accepted is a good way to prove yourself for commit access. Oh, and we also have some review guidelines for the first time to help developers and reviewers know how things should be measured.

3. People with commit access don't need to go through code review. However everyone is encouraged to get someone to look at their code as they work, particularly for large or complex developments, and everyone should be attempting to review their own code.

4. The old "Core team" no longer exists. It many ways it hasn't existed for a while due to departures. The small amount of admin stuff that exists (sysadmin, builds, paying the bills) will be handled by me and jpab.

5. The new Development Team page lists people who consider themselves experts on various aspects of the game. It'd be good if everyone that knows a lot about one or more parts of the game list their name and skills there to make it easier for contributors to find the right person to talk to.

I really want to stress how important good communication will be from now on. Very soon many of you will have complete control to do whatever you like to the game. Its really important that you talk to others and make sure that we're all moving forward in the same direction.

And make sure you're always having fun :)

Further reading:

http://pioneerwiki.com/wiki/Development_team
http://pioneerwiki.com/wiki/Commit_access
http://pioneerwiki.com/wiki/Code_review

and an interesting blog post that we drew some inspiration from:

http://felixge.de/2013/03/11/the-pull-request-hack.html

Cheers,
Rob N.

[walterar]

It can work. Only one problem. Each has its own game in the head.

[jpab]

It can work. Only one problem. Each has its own game in the head.

This will always be a problem I think; there is no easy solution. The best we can do is to accept that sometimes there will be disagreements, and trust each other to do things for the good of the project as a whole.

[lwho]

I really want to stress how important good communication will be from now on. Very soon many of you will have complete control to do whatever you like to the game. Its really important that you talk to others and make sure that we're all moving forward in the same direction.

One suggestion for a little bit of automatic coordination: If someone intends to work on an issue (e.g. fix a reported bug) he should assign the issue to himself so everyone can see that someone (and who) is taking care of it. Of course, people without push permission can also work on an issue. In that case, they should add a comment that they are working on it and someone with the permissions should then assign the issue to him.

For work in progress without an existing issue, I suggest that one makes an issue about it early (even before there is something to show in a pull request) and assigns it to oneself (or asks for someone with the permissions to do that).

Since that is a hobby project, it may of course happen, that one does not intend to finish the work anymore. In that case the issue should be re-assigned to nobody (or closed if that is more appropriate for a case). I expect that to be forgotten often ;) But if we are disciplined with the above suggestions, the issue will be marked with the last one working on it, and he can be asked directly if he is still working on it, if someone else wants to step in.

So, it will be generally visible who works on what an gives a place where coordination between work items can be done.

Basic discussion should happen here, I think.

What do you think about those suggestions?

[jpab]

One suggestion for a little bit of automatic coordination: If someone intends to work on an issue (e.g. fix a reported bug) he should assign the issue to himself so everyone can see that someone (and who) is taking care of it. Of course, people without push permission can also work on an issue. In that case, they should add a comment that they are working on it and someone with the permissions should then assign the issue to him.

I think this is worth trying. Although I don't think github provides a mechanism to assign issues to people who don't themselves have push access, so for that we will have to rely on just a commented added to the issue, as you said.

For work in progress without an existing issue, I suggest that one makes an issue about it early (even before there is something to show in a pull request) and assigns it to oneself (or asks for someone with the permissions to do that).

I think this is a good idea for changes that have already been discussed or that don't need design discussion. For larger things I think there's a risk of splitting discussion between the github issue list and this forum. But even so, discussion somewhere is better than no discussion at all—even if sometimes things get put in the "wrong" place.

Basic discussion should happen here, I think.

I agree.

John B

[impaktor]

Perhaps thse suggestions should go on the wiki?

[lwho]

Perhaps thse suggestions should go on the wiki?

That's what I was intending to do. I just wanted to discuss it here first. And the proceeding we agree on can be put on the wiki then.

Although I don't think github provides a mechanism to assign issues to people who don't themselves have push access

That's a pity. I thought those could only not assign, but still be assigned. But indeed I see only a very small list of people on the assign dropdown which does not seem to be extensible. So, if filtering for unassigned issues this will still include the ones, which are logically assigned, but to people without push access :(

For larger things I think there's a risk of splitting discussion between the github issue list and this forum.

I agree. So maybe the guideline should be:

1. Start a discussion here.
2. Create a one-liner github issue assigned to you with a link to the discussion here, so that it's visible on github, but the discussion happens here.
3. State that #1 can be left out if the topic was already discussed or is a simple bugfix/feature that does not need design discussion. So, opening a discussion here, is the rule with small stuff being the exception from the rule.

I'm stressing the GitHub issue here, because then we have one single place where it is always visible. And GitHub is a better place for that than here, because small stuff does not need a discussion here, and it lands in GitHub sooner or later anyway. So, GitHub would not be the place where all the work would happen, but the anchor point.

[jpab]

So maybe the guideline should be:

1. Start a discussion here.
2. Create a one-liner github issue assigned to you with a link to the discussion here, so that it's visible on github, but the discussion happens here.
3. State that #1 can be left out if the topic was already discussed or is a simple bugfix/feature that does not need design discussion. So, opening a discussion here, is the rule with small stuff being the exception from the rule.

Sounds good to me.

[FluffyFreak]

Yup, I agree.