The following is a general commentary post. I'm not attempting to call out any one specifically on anything, even though specific instances are related in the dialogue.
12/24/09 @ 00:45:25
Builds posted with some usage instructions.
Generalized commentary about A: How to use it and B: How it was implemented.
12/27/09 @ 17:49:35
Inquiry as to use of the font tool to make vf fonts from original coder.
12/29/09 @ 23:41:27
Committed to Trunk as 5751. 5752 is further committed to adjust it's implementation.
Later commit 5755, UI Window fix on Font code committed.
12/30/09 @ 03:05:03
General inquiry as to font size correction that original coder experienced.
Admission that testing by original coder not yet done.
@ 09:21:09
Original coders work around for sizing issue called out as a brutal hack.
Yet, sizing issues present in the committed code (potentially leading to the aforementioned 5755 commit)
Conversation devolves from there, with original coder essentially being told that they will no longer in any way ever be listened to, supposedly inferring the entire SCP team will go along with this, despite of it being a community project.
Now, normally, we get feature requests where nobody even thinks about what they are asking for, outside of some vaguely defined notion as to what it will entail, maybe. There are by and large plenty of requests that do have a lot of thought put in to them first as well, just so nobody assumes that I'm negatively making generalizations.
But in this case, we got actual code on a feature that a project wanted to see implemented for their release. Now, as to how _well_ that code was written is not my place to say, I'm still learning. And what mistakes I have made have been in general pointed out to me in a much better fashion than they have been pointed out here.
If what you get from somebody constantly requires reworking, in what fashion has it been pointed out that it still needs to be worked on? It's one thing to say "Review of the code shows that it is usable and the idea itself has a significant merit, but for the purposes of allowing the best forward compatibility with the code base, could you look at this example of the changed code and see if that still does what you are intending?". I mean, if I got a response like that, I'd be pretty happy that my idea had enough merit that somebody was willing to take the time to go over it and share with me a way to make it (and myself) better. That's the professional thing to do.
Unfortunately, what we have here instead is the Personal aspect response of "this is ugly, brutal and a hack, in spite of being an idea of merit, so I'm going to do it my way rather than yours and disregard what you have to say about what you intended because you obviously have it all wrong anyway."
Just as unfortunately, the responses as given to these statements begin to slip from being technical and to the point into also slipping into the more personal response area. Potentially understandable as most people will tend to respond to personal statements in a personal fashion.
Now, I realize there is a lot of potential history here that I am not privy to. Nor do I want to be. But any idea of merit, regardless of source, should have just as much of an equal unbiased ability for consideration and inclusion to the code base as any other.
Or if it's not to be included or considered in the code base it should be for purely professional and technical reasons only, rather than personal, and those reasons should be clearly and concisely laid out for the original coder to contemplate and provide a means by which to either meet the challenge and revise the code or propose a solution to collaborate on. Or at the very least have some idea as to what prerequisites need to be accomplished first before it can happen that they could maybe then lend assistance on.
The strength of a community is not how easily everybody can see eye to eye with each other, but in how well it can continue to operate EVEN WHEN people don't see eye to eye. I think we manage a pretty good degree of collaboration, even in spite of personal interaction issues that continually creep into what should be purely technical aspects and future development considerations.
