5 fixed grammar
source | link
  1. You can quit. Not the most constructive thing to do, but sometimes itsit's the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words.

  2. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others continue to have a little ego-fest of their own. Your new project will simply compete with the old and its up to you whether you make a success of it, or the old one beats you in terms of users and features.

  3. You can engage with the rest of the development team on the project to voice your concerns. Don't make it personal, but make out that you're unhappy with code churn, or lack of established quality processes, or unhappy that the new decisions are just pushed out without agreement from everyone. You'll either be told that nothing's wrong enough to change, or you'll get a few others agreeing with you that the team needs to fix things up. That might end up with the disruptive guy losing his commit access. Maybe you'll all agree that some of the changes are not an improvementimprovements and the project needs to be reverted. (This latter option is the most likely outcome, unless it turns into a massive argument of entrenched opinions.)

It can be difficult when someone comes along and changes the safe and comfy routines you've become used to, but it could be said that having someone come along and shake up the old, cozy practices is aare good thingthings in itselfthemselves.

  1. You can quit. Not the most constructive thing to do, but sometimes its the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words.

  2. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others continue to have a little ego-fest of their own. Your new project will simply compete with the old and its up to you whether you make a success of it, or the old one beats you in terms of users and features.

  3. You can engage with the rest of the development team on the project to voice your concerns. Don't make it personal, but make out that you're unhappy with code churn, or lack of established quality processes, or unhappy that the new decisions are just pushed out without agreement from everyone. You'll either be told that nothing's wrong enough to change, or you'll get a few others agreeing with you that the team needs to fix things up. That might end up with the disruptive guy losing his commit access. Maybe you'll all agree that some of the changes are not an improvement and the project needs to be reverted. (This latter option is the most likely outcome, unless it turns into a massive argument of entrenched opinions.)

It can be difficult when someone comes along and changes the safe and comfy routines you've become used to, but it could be said that having someone come along and shake up the old, cozy practices is a good thing in itself.

  1. You can quit. Not the most constructive thing to do, but sometimes it's the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words.

  2. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others continue to have a little ego-fest of their own. Your new project will simply compete with the old and its up to you whether you make a success of it, or the old one beats you in terms of users and features.

  3. You can engage with the rest of the development team on the project to voice your concerns. Don't make it personal, but make out that you're unhappy with code churn, or lack of established quality processes, or unhappy that the new decisions are just pushed out without agreement from everyone. You'll either be told that nothing's wrong enough to change, or you'll get a few others agreeing with you that the team needs to fix things up. That might end up with the disruptive guy losing his commit access. Maybe you'll all agree that some of the changes are not improvements and the project needs to be reverted. (This latter option is the most likely outcome, unless it turns into a massive argument of entrenched opinions.)

It can be difficult when someone comes along and changes the safe and comfy routines you've become used to, but it could be said that having someone come along and shake up the old, cozy practices are good things in themselves.

4 A few quick grammatical & flow edits. This answer will be featured at Ars Technica this weekend.
source | link
  1. You can quit. Not the most constructive thing to do, but sometimes its the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words.

  2. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others continue to have a little ego-fest of their own. Your new project will simply compete with the old and its up to you whether you make a success of it, or the old one beats you in terms of users and features.

  3. You can engage with the rest of the development team on the project to voice your concerns. Don't make it personal, but make out that you're unhappy with code churn, or lack of establishestablished quality processes, or unhappy that the new decisions are just pushed out without agreement from everyone. You'll either getbe told that nothingsnothing's wrong enough to change, or you'll get a few others agreeing with you that the team needs to fix things up. That might end up with the disruptive guy losing his commit access. maybeMaybe you'll all agree that some of the changes are not an improvement and need to go back to the old onesproject needs to be reverted. (thisThis latter option is the most likely outcome, unless it turns into a massive argument of entrenched opinions.)

It can be difficult when someone comes along and changes the safe and comfy routines you've gottenbecome used to, but it could be said that having someone come along and shake up the old, cosycozy practices is a good thing in itself.

  1. You can quit. Not the most constructive thing to do, but sometimes its the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words.

  2. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others continue to have a little ego-fest of their own. Your new project will simply compete with the old and its up to you whether you make a success of it, or the old one beats you in terms of users and features.

  3. You can engage with the rest of the development team on the project to voice your concerns. Don't make it personal, but make out that you're unhappy with code churn, or lack of establish quality processes, or unhappy that the new decisions are just pushed out without agreement from everyone. You'll either get told that nothings wrong enough to change, or you'll get a few others agreeing with you that the team needs to fix things up. That might end up with the disruptive guy losing his commit access. maybe you'll all agree that some of the changes are not an improvement and need to go back to the old ones. (this latter is the most likely outcome, unless it turns into a massive argument of entrenched opinions)

It can be difficult when someone comes along and changes the safe and comfy routines you've gotten used to, but it could be said that having someone come along and shake up the old, cosy practices is a good thing in itself.

  1. You can quit. Not the most constructive thing to do, but sometimes its the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words.

  2. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others continue to have a little ego-fest of their own. Your new project will simply compete with the old and its up to you whether you make a success of it, or the old one beats you in terms of users and features.

  3. You can engage with the rest of the development team on the project to voice your concerns. Don't make it personal, but make out that you're unhappy with code churn, or lack of established quality processes, or unhappy that the new decisions are just pushed out without agreement from everyone. You'll either be told that nothing's wrong enough to change, or you'll get a few others agreeing with you that the team needs to fix things up. That might end up with the disruptive guy losing his commit access. Maybe you'll all agree that some of the changes are not an improvement and the project needs to be reverted. (This latter option is the most likely outcome, unless it turns into a massive argument of entrenched opinions.)

It can be difficult when someone comes along and changes the safe and comfy routines you've become used to, but it could be said that having someone come along and shake up the old, cozy practices is a good thing in itself.

3 edited body
source | link
  1. You can quit. Not the most constructive thing to do, but sometimes its the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words.

  2. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others continue to have a little ego-fest of their own. Your new project will simply compete with the old and its up to you whether you make a success of it, or the old one beats you in terms of users and features.

  3. You can engageYou can engage with the rest of the development team on the project to voice your concerns. Don't make it personal, but make out that you're unhappy with code churn, or lack of establish quality processes, or unhappy that the new decisions are just pushed out without agreement from everyone. You'll either get told that nothings wrong enough to change, or you'll get a few others agreeing with you that the team needs to fix things up. That might end up with the disruptive guy losing his commit access. maybe you'll all agree that some of the changes are not an improvement and need to go back to the old ones. (this latter is the most likely outcome, unless it turns into a massive argument of entrenched opinions)

It can be difficult when someone comes along and changes the safe and comfy routines you've gotten used to, but it could be said that having someone come along and shake up the old, cosy practices is a good thing in itself.

  1. You can quit. Not the most constructive thing to do, but sometimes its the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words.

  2. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others continue to have a little ego-fest of their own. Your new project will simply compete with the old and its up to you whether you make a success of it, or the old one beats you in terms of users and features.

  3. You can engage with the rest of the development team on the project to voice your concerns. Don't make it personal, but make out that you're unhappy with code churn, or lack of establish quality processes, or unhappy that the new decisions are just pushed out without agreement from everyone. You'll either get told that nothings wrong enough to change, or you'll get a few others agreeing with you that the team needs to fix things up. That might end up with the disruptive guy losing his commit access. maybe you'll all agree that some of the changes are not an improvement and need to go back to the old ones. (this latter is the most likely outcome, unless it turns into a massive argument of entrenched opinions)

It can be difficult when someone comes along and changes the safe and comfy routines you've gotten used to, but it could be said that having someone come along and shake up the old, cosy practices is a good thing in itself.

  1. You can quit. Not the most constructive thing to do, but sometimes its the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words.

  2. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others continue to have a little ego-fest of their own. Your new project will simply compete with the old and its up to you whether you make a success of it, or the old one beats you in terms of users and features.

  3. You can engage with the rest of the development team on the project to voice your concerns. Don't make it personal, but make out that you're unhappy with code churn, or lack of establish quality processes, or unhappy that the new decisions are just pushed out without agreement from everyone. You'll either get told that nothings wrong enough to change, or you'll get a few others agreeing with you that the team needs to fix things up. That might end up with the disruptive guy losing his commit access. maybe you'll all agree that some of the changes are not an improvement and need to go back to the old ones. (this latter is the most likely outcome, unless it turns into a massive argument of entrenched opinions)

It can be difficult when someone comes along and changes the safe and comfy routines you've gotten used to, but it could be said that having someone come along and shake up the old, cosy practices is a good thing in itself.

2 added 12 characters in body
source | link
1
source | link