How do we handle changes going forward

[Kasper Garnæs]

With dypa on board we are going from a single active developer to a growing number of contributors. It would be useful If we could establish some basic rules for future development.

My 2 cents:

- All changes to the master branch should be made using pull requests (we already do this most of the time)
- Do not merge your own pull request (we have to actively keep an eye on each others work)
- Changes should should strive towards increasing or at least maintaining the quality of the project (code coverage, coding standards etc.)
- Changes to master which affects users (new features or bugfixes) should be released as soon as possible.

What do you think?

/kasperg

[Fredrik Wallgren]

I think all of your cents are good :)

Having a master branch that always "compiles" is a great idea, and makes item four, continuous deployment, easier.

Maintaining/increasing quality is also a great "rule", leave things a little better than you found it.

The only thing I see a problem with is, as long as we don't get more contributors, is not merging your own pull requests. For new features I think it's a good idea, because they don't have to be included as soon as possible. But bugfixes may be exempted from the rule if they need to be included as soon as possible. I know I won't have time to do as many merges as I'd like, so they may be left hanging. What do you think?

* Use semantic versioning and continuous deployment, master should always "compile"

* Use pull requests to have a nice interface to discuss changes if need be, also to get some code review when someone merges it

* Maintain/improve code quality with each change. We should be extra careful to follow this, so we ask other contributors to include tests, convert code to standard etc.

* Try to get someone to look over/merge your pull requests

* Follow the psr-2 coding standard? Thinking about this commit https://github.com/wsdl2phpgenerator/wsdl2phpgenerator/commit/458e526ca7c25f6b44f0c245d3c7aac9f23a902d should new code try to follow it? Perhaps rewritten code too?

* Don't reinvent the wheel, try to use other projects where it makes sense. Like your good work with replacing custom CLI code Kasper (https://github.com/wsdl2phpgenerator/wsdl2phpgenerator/pull/52).

That is my thoughts on this. Some basic guidelines, but not too rigid so it becomes a burden to contribute. It's a fine line between what helps the project and what makes it to hard to contribute to.

Great initiative to bring this up!

Regards,

Fredrik 

[Kasper Garnæs]

On Monday, November 18, 2013 5:34:41 PM UTC+1, Fredrik Wallgren wrote:

The only thing I see a problem with is, as long as we don't get more contributors, is not merging your own pull requests. For new features I think it's a good idea, because they don't have to be included as soon as possible. But bugfixes may be exempted from the rule if they need to be included as soon as possible. I know I won't have time to do as many merges as I'd like, so they may be left hanging. What do you think?

I think the whole review of pull requests may be a problem going forward.

We currently have 8 pull requests (4 of my own) where the last comment was made ~2 weeks ago. Most of them will go nowhere if we cannot merge our own pull requests - at least after a certain window of time where other developers can chime in.

* Maintain/improve code quality with each change. We should be extra careful to follow this, so we ask other contributors to include tests, convert code to standard * Follow the psr-2 coding standard? Thinking about this commit https://github.com/wsdl2phpgenerator/wsdl2phpgenerator/commit/ 

458e526ca7c25f6b44f0c245d3c7aac9f23a902d should new code try to follow it? Perhaps rewritten code too?

I think these should be the goals, yes. I'm not sure we should always enforce them depending on the importance of the proposed change and our own willingness to fix any remaining problems ourselves.