On Wed, 17 Dec 2003, bulia byak wrote:

...

Perhaps since we're not too crowded for space yet, and since the bug now has a solution, that it would be prudent to let the spiral tool remain until Nathan has a replacement for it?

Yes, and only if that replacement is a strict superset.

I'd support that as the decision, even if it was just a "close" superset. Let's restore the spiral button until such time as a replacement is available. If nothing else, it doesn't hurt anything to keep it, and it will avoid freaking anyone out. ;-)

Sorry for sounding harsh, but this desicion really appalled me. I hope I convinced you to revert this decision, and moreover I hope you don't take decisions that suddenly kill almost a thousand lines of good code without a serious reason and a good discussion.

Now, remember that the principle in action here is "patch first, discuss later". Mental patched, now we're discussing. ;-)

We had another case like this earlier this week when some status bar functions were added that assumed use of global variables. The initial patch to the code appalled another developer, but by discussing it subsequently, good solutions were worked out.

My point is this: If people feel that making a controversial change will require a lot of discussion upfront, then that will discourage them from trying out ideas that push the envelope. The danger is that one ends up endlessly debating trivialities and never getting real work done. We had deliberately chosen this approach because we wanted to have development be open and with few bottlenecks (a committee can be as frustrating of a bottleneck as any strict code integrator).

The approach is great for maintaining momentum, however the price is that it increases the likelihood of stepping on toes and surprising one another. There are ways to mitigate this however, that we all should follow:

1) Use a roadmap. This way it's less surprising when people do major changes. Compare how little controversy was generated with the rename of all the files to .cpp than any one of the changes that never appeared on the roadmap. This is why roadmaps are worthwhile.

2) Communicate. A lot. And in multiple mediums. Give people time to comment, digest, agree, disagree, etc. Some people are afraid to use email, or don't like chat, or never look at the website. Putting info up in multiple places ensures that you catch the eye of everyone with an interest in the project. And on the other side of the coin, highly active developers need to pay attention to all the mediums, and if they ignore one or two of them should expect to be surprised from time to time.

3) Be patient with each other. The risk and damage of getting imperfect code into the codebase is miniscule compared with the damage of letting ill feelings towards each other build up. Bad feelings can destroy a project faster than anything else.

4) Be calm. In open development geared for being innovative, people are going to make changes that will freak people out from time to time. Changes *can* be reversed, inferior code rewritten, and bugs fixed.

I think especially right now, when we're in kind of a 'freeform' style of development due to the holidays, it's very important that we keep these in mind, lest things get too chaotic.

Each of us are doing well in some of these areas, and if each of us can work on the areas where we're weak, then the project as a whole will become stronger.

We should not take any serious feature decisions without as wide discussion as possible, and especially when we REMOVE something.

In Wikipedia we had a principle sort of similar to the one we're using here, which was "Be bold in updating pages". That is, for some topic that is not controversial, no one will have a problem if you update the page, and for a controversial topic it'll take forever to reach agreement if you have to discuss everything first. So just make the change and if its controversial, there'll be a discussion and stuff will get worked out, and most likely the topic will be the better for all the extra attention it receives.

So while I do agree that discussion is *very* important, and in this case agree with you that the removal of the spiral should have been mentioned on the list, I would disagree that feature decisions _must_ be discussed before changes are made. I think what Mental did was okay. He got buy-in from several people, then patched, and now we're discussing it. The change was made in development CVS, not in a released version, so it was guaranteed that everyone would either notice it missing and start a discussion, or not notice it and prove it was unnecessary.

Technically, I had preferred Nathan's proposal to replace the spiral tool with a superset, rather than removing it immediately, but I really think we need to support developers' freedom to change the code when we're not in feature freeze, as long as we also leave open the ability to discuss and revert or revise the code subsequently. Keep in mind that for every 1 controversial change, we're allowing 10 or more other changes to easily get in.

Jabber is fine for quickly discussing small things, but this is a serious change which requires a balanced, slow, thorough discission. Jabber is not suited for this kind of discussions.

With all due respect Bulia, I think this comment is partly colored by the fact that you do not use Jabber. Those who do use it find it a very good medium for both small things and large. Some of the discussions going on there are very fruitful and very deep, such as njh and pjrm's discussions about C++-ification of the point code, or Jon's ongoing discussions with color tools. It is an excellent way to get immediate feedback, float ideas, and work out decisions. It can be much faster and more personal than email. I think a lot of us (including yourself) would feel more comfortable if you could join in the discussions on Jabber more regularly.

Again, I agree that this should have been mentioned on email. I feel the best communication is multi-pronged. Email, chat, wiki, and the website all should be used together; each has a different set of benefits, and if they're leveraged together then communication won't be an issue. If we don't make good use of them, then we are going to have to deal with a lot of miscommunication problems in the future.

I hope this email isn't too long, but I wanted to be sure to give my thoughts on how we assure that we continue to work well as a team. If we are attentive to adopting good practices, we'll make sure that we don't have problems in the future. Publish plans, communicate thoroughly, be patient, and things will go well. We need to remain thankful that we have each person's help, and thankful that we have a friendly and productive project; in the long run this will be more important than if there are imperfections in the code.

Bryce