Log Filtering

[Aiwendil]

Well, you submitted request and code at the same time, so I'd expect approval of the idea to take longer, but with simultaneous code integration, basically closing the request with the approval (if approved of course).
I've also seen months passing before a first comment is made on a request. Makes sense to me for "low" severity.
That plus the many reasons why some code could be disapproved... But at the end of the day, I'd still be optimistic.

as for yours Aiwendil - reviewing them takes a bit time - especially with feature requests
FRs have to be approved by a leader or even a director
additionally submissions have to be reviewed with regards to code-style, doing it "the right way", etc.

Yeah, got it by now. Submitting code is a bad idea as it would been much faster to only review a feature request and discard or accept it and then have the dev-team write the proper code for it. When a feature request that already includes code is submitted the reviewing of only the feature idea takes much longer as it depends also on the code submitted and is maybe rejected in total because of coding style issues or other problems with the source-code. In the end submitting code has the contrary effect of what is was meant for...it makes it harder and is no help at all. It doesn't help at all to get features implemented faster the PS team gives low priority but which some players would like to have nonetheless. If you want to submit code the best way is just to become a PS prospect...and then work on the tasks that are given to you instead of what you think would be nice to include in the game. If you don't want to get in the PS team better stay with submitting only the ideas of feature requests as this might get them faster (if accepted) in game than if there was already a suggestion how to include it in the code along with the idea. It seems I have to apologize to LigH for coming up with patches for his scriptable login idea as this made it far more unlikely to get implemented soon.

I guess I am the only one who sees a problem with this feature request-workflow for a opensource project.

[RlyDontKnow]

Don't get sarcastic and take it all wrong -.-
the review of the code isn't related to the approval of the feature request at all
if there's something wrong with the code, it'll be tweaked straight away or you'll be asked to fix the issues.

[Aiwendil]

Don't get sarcastic and take it all wrong -.-

Ahm...two years too late for that.

But for the rest, true you didn't state explicitly that the approval of the feature request and the review of the code are related.

additionally submissions have to be reviewed with regards to code-style, doing it "the right way", etc.

So this sentence has to be taken like: "First it needs time to get a word of some higher-ups if this is wanted at all and then it takes additional time to review the submitted code"? That doesn't really change much about what I said before. For the rest of that comment:

The point is that unless otherwise directed by the team, the packaged distro client is what should be used with our servers.  If you want to try to improve the client, build your own server and test it on your own, and submit it to a dev for consideration if it fixes a bug or enhances a feature to benefit the entire player base.  You'd be encouraged to discuss your intent with a dev first to avoid wasting your time (and ours), and you probably should consider applying to the team at contributor or prospect level to get a more clear understanding of the development process and direction.

So what I said still stands...if you submit code it will take longer and you better apply for the team if it should be included in the game.

[RlyDontKnow]

So what I said still stands...if you submit code it will take longer and you better apply for the team if it should be included in the game.

not at all. put aside prospects choose their tasks themselves, too, there's no difference whether you're a team member or not.
the FR still has to be approved first and the code still has to be reviewed

[novacadian]

My experience of QC (Quality Control) with even simple LPC on MUDs is a process that takes time and is often not appreciated by those submitting. Both sides of the equation are understandable. The fact is, though, that good QC is required for quality software development. Just the nature of the beast from my experience.

- Nova

[kaerli2]

My experience of QC (Quality Control) with even simple LPC on MUDs is a process that takes time and is often not appreciated by those submitting. Both sides of the equation are understandable. The fact is, though, that good QC is required for quality software development. Just the nature of the beast from my experience.

- Nova

Hint: that's what TDD/BDD techniques are for.  After-the-fact QC measures are a poor substitute for a strong unit test framework.

[RlyDontKnow]

Hint: that's what TDD/BDD techniques are for.  After-the-fact QC measures are a poor substitute for a strong unit test framework.

even a strong unit test framework can't guarantee things are done properly (i.e. verify proper code style and it actually being placed in the right classes, etc.) nor can it approve FRs, it can just guarantee it works in the common/border cases

[zinder]

For the original topic, I haven't played in a while so i am not all that current on chat logging options. But perhaps a chat logging inspired by Logging Frameworks would be good idea. For each channel you could give a number of destinations.

For example usage you have an allChannels.log, where messages of all channels are logged. You add guild.log to the guild channel and you add IC.log to guild, tell, chat and group. When you play Planeshift, all messages on the guild channel get added to allChannels.log, guild.log and IC.log. Tell messages get only added to IC.log and AllChannels.log. System messages only appear in AllChannels.log. Channels without any destination don't get logged at all.


A unit test framework helps to find implementations not working as the test writer understood the specification. It does not speed up arriving at the specification, nor does it guarantee the test implementation is correct for the specification. It only checks the working of an implementation, not the coding style. As the previous poster already said, coding style is beyond a unit test framework.

An implementation that looks like decompiled optimized object code will pass a unit test framework. But it should never pass quality control on any code base. There are various flavors of code that works, but shouldn't be accepted.