Feedback forums hostility

[Aranclanos]

Bottom post of the previous page:

I don't really like polls, while they sound democratic and fair, they really aren't. Mostly they consist on politics, with the huge need of people who made the commit to quickly start doing first impressions about the change in ooc (because most people will vote only hearing one side and then forget about it) so people can vote on his favour, but in general people reject change by default until they can get used of it, and the asks to revert will come before that.
For the game's future, the most popular decision isn't always the best too. A great example is the movement speed or the UI change like inti says
--
Anyways, I don't really want to ramble a lot about polls, I wanted to focus mainly on the kind of content of these forums, with the OP posts and the answers following it. I like the idea of the template, specially for the titles of the thread, who sometimes they just start like an attack, at least that's the feeling from some of them.
Another question, should there be a difference between the feedback of commits that just got merged or didn't and the ones that can be actually played on the servers?

im sorry if the posts are being too big btw, but I really appreciate if you take your time to read them

[paprika]

Singulo has long replaced feedback when it comes to code shitposting anyway.

[oranges]

Thanks pap

[paprika]

<3

[lumipharon]

Slow space is unpopular for an actual reason though. It makes all content outside the station extremely fucking tedious, and like when HG's speed change first went in, mobs (or in this case, mobs in space) go just as fast as before, which is fucking awful.

Airlocks are just a joke now, if someone takes one step out of one, they're literally fucked and cannoted be saved, because you're too slow to overcome space wind. This doesn't make space feared and interesting, it makes it frustrating a pointless. I once saw a small bomb make a 1 tile breach in a corridor. I sat there and watched as the mime walked down the corridor, got stuck in the ONE tile breach, got stuck, went into crit, and would have died if I didn't drag him out. If you want something more realistic you go bay's explosive decompression, not tile shuffling because of space wind until you die.


All that said however, some people are pretty rediculously strong against basically any change, good and bad.

[adrix89]

I'd be all for this but I'm concerned about the amount of time and effort it would take to manage ingame polls for every single feature added. Also, having to revert something months after it was added can be a pain. And there's the concern of people skewing the polls by mutikeying.

We could instead have admins create custom votes ingame (like restart votes but about whatever recently added feature the admin chooses) during lobby time at peek hours a couple days in a row to get a decent idea of the players opinions, and then post the results in the appropriate feedback thread.

Obviously we don't need to go full autist, the forum polls will solve most of the issues, only the major and controversial changes would need trials with ingame polls.
How we get the votes from the game can be any number of ways.

The problem with voting is apparent when you look at things like the newer UI change.

The old UI was awful compared to this one. When it was added, everyone was bitching at coderbus for changing it and saying it was terrible for a few weeks, and then it died down.

If there had been a poll at that time, it would have been starkly negative, even for something as great of an improvement as it was.

Which would be the point of the trials, we could organize a bit and have a change for a month and leave the voting for the last week. This should let people get used to whatever.

with the huge need of people who made the commit to quickly start doing first impressions about the change in ooc (because most people will vote only hearing one side and then forget about it)

This is bad how?

but in general people reject change by default until they can get used of it, and the asks to revert will come before that.

Which could be solved with the above mentioned trial method.

A great example is the movement speed or the UI change like inti says

Movement speed change...good...

The problem is that it really is about control, players have no voice when it comes to gameplay decisions and coderbus gets more and more isolated. They are FRUSTRATED. So you get drama and hostility, its inevitable whatever you do.

Another question, should there be a difference between the feedback of commits that just got merged or didn't and the ones that can be actually played on the servers?

More information is always better.

[Miauw]

please dont turn this thread into shitting on paprika 2: electric dongaloo. make a separate thread for that or something.

Also, polls really don't help in game design.
"this change is bad" is very unhelpful. (So is "this change is good", I guess, but if people think its good theyll probably keep thinking it's good even if you don't change it.)
So, you've got your fancy schmancy poll, the majority of players thinks your change is bad five minutes after the server updated.
What are you going to do with that information? Are you just going to revert your change and be done with it, potentially losing a great feature? Are you going to ignore the polls, creating a shitstorm?
And even if you decide that it should be better, where the fuck do you start? You only know that your change is disliked. That's not useful information.
Who knows, maybe your feature is completely fine and people just need some time to get used to it!

Imo, the best way to gather feedback is just to hang around in dchat (OOC is usually fairly empty). A poll can't capture arguments and can't capture which part of a new thing people dislike.

Polls really aren't good except for sprite changes maybe. (for example, bluebay).

[adrix89]

Are you just going to revert your change and be done with it, potentially losing a great feature? Are you going to ignore the polls, creating a shitstorm?

The problem is setting the code in stone IS the problem.
It first sets the barrier of entry high so it stops experimentation and once its on the server everyone is reluctant to revert it regardless how many problems arise.
In other words there is no flexibility, no iteration.

Imo, the best way to gather feedback is just to hang around in dchat (OOC is usually fairly empty). A poll can't capture arguments and can't capture which part of a new thing people dislike.

Polls is not about feedback, it is about deciding what should be done with it, either accept, revise or revert.

[dezzmont]

Hey. So back when I was in the bus one of my primary jobs was trying to keep the coding team, admin team, and playerbase on the same page. A large part of that was monitoring feedback. I had a lot of experience with that hostility both in the forums and behind the scenes and I honestly got some 2 cents to put out, with the amendment that it has been a very long time and I don't follow the drama. That said this thread seems to be a symptom of the same problem that was around back then.

A lot of players are amazingly bad at expressing themselves, thinking about the game as a system and not something they play, and just dealing with people. That sucks, and I have had to deal with some really screwed up ragemonsters. But most of the time when I went behind the scenes it was pretty easy to calm them down when I just pointed out how destructive and non-productive their actions were. It mostly was a specific very problematic and opinionated person mind, but it happened with everyone. It was less therapeutic than bureaucratic but pointing out that their actions were just making them look bad worked.

I never had any real success with the code team. While the playerbase can feel entitled, the code team back then was entitled on a whole different level. Every coder felt empowered to make very large changes to the game with little oversight or direction because there were no designers. To be a coder was to be a designer no matter how transparent it was that you were not talented at actual game design. Many things got pushed through that absolutely shouldn't have. The strawberry jam overlay and diagonals for example were put in because coders were empowered to do it and almost everyone had commit. There was even a bit of a controversy when a coder repeatedly was caught trying to sneak in rules changes through the code when the admins shut them down. It was a mess, and they had an extremely delicate personality. And while everyone involved recognized their actions as shitty, both in and out of coderbus, nothing could really be done because of a really big us vs them mentality that makes coders super defensive.

And they honestly should, because basically every change they made was often attacked. But it was attacked because coders, at least then, had almost no oversight and answered to no one. It doesn't help that the code team's leadership basically was either absent or infighting. But the only real way for players to force a coder to accept feedback was to be loud as hell. Logically pointing out that the game in no way was set up to account for diagonal movement and that it would break the map something fierce wasn't enough, people needed to shout down this person because that was the only method for affecting change, controversy and anger, because coders are in some ways artists and get attached to their product. Everyone can hate something you did and point out why it sucks nicely but if you made it an d you have the power to add it in whenever you like you probably are just going to 'let the haters hate.'

Obviously things have gotten much better. There are only 7 people on the github as far as I can tell compared to the some odd 40 people that had commit in the day. But what may help with some of the hostility is seperating the idea of a coder and the idea of a designer, because they are entirely seperate skill sets. People dedicated to design, to appreciating complex systems, game theory, and player behavior could have no idea how to code but still be more qualified to comment.

As for the main question, if this forum should be set up like FNR? No. Everyone is involved, coders are not some infallible cast. I have personally witnessed so many SNAFUs in coderbus, both personal failures to be a decent human being and just failure to think through the ramifications of a feature that's sole virtue is 'I want to make it' that it is clear to me coderbus can't be entirely self regulating in terms of designed. No game should be designed by democracy of course, they should be designed, and part of design is people tearing apart your work and making every little flaw apparent. You don't need to be a chef to know the food is burnt. What should happen is an attitude of respect. You should be willing to in any collaborative process of design, feel free to attack something that doesn't work, as long as you can recognize that sometimes a flaw is actually a trade off. What you shouldn't do is attack people. That goes for being a dick to coders as well as acting like just because you can write up a change you are somehow above other people.

As has been said multiple times in this thread, FNR threads only allow involved parties. Everyone is an involved party here.

[adrix89]

But what may help with some of the hostility is seperating the idea of a coder and the idea of a designer, because they are entirely seperate skill sets. People dedicated to design, to appreciating complex systems, game theory, and player behavior could have no idea how to code but still be more qualified to comment.

We can't have designers, there is no one at the top that is a designer or trusted enough for the position and we are not that organized anyway.
What we should be is flexible let coders change stuff and experiment but be absolutely willing to change it back. Have systems in place for accountability.
Keep what works, throw what doesn't and be back for another shot at it later with something better.

Our best bet is to be iterative.

[MisterPerson]

Yes, but who decides when it's time to change things back? Reverting anything that gets a relatively popular thread on feedback will just result in a ton of wasted time because people will complain about things that aren't problems. They may also complain about things that are necessary for whatever reason or changes that negatively impact them but positively impact the game as a whole. Or maybe something is just controversial and there's many detractors but also many silent supporters. Plus, what's the exact point where something is unpopular enough to require a revert? What gets reverted and what has someone try to fix things?

I don't think a fragmented, segregated design plan can really function these days. And even if it did, a strong leader with a vision for the game is a better solution anyways. I mean technically speaking the headcoders are also lead designers, and I'm not sure about anyone else but I've deferred what should be done based on their input alone. For example, I happened to have the appropriate file open when HG mentioned he'd prefer if space movement wasn't sanic fast, and since I was already there and liked the idea, I decided to give it a go. If HG hadn't have said anything, I wouldn't have even bothered.

I think much of the general frustration from feedback is because playerbus basically has no real input on design choices and feel very marginalized because of that. Instead of very narrow and specific discussions about individual items, I'd love to see more general discussion threads on feedback about the overall direction the game needs to go. Topics like "how dangerous do we want hull breaches to be? deadly? an inconvenience?" or "how much chaos should an average round experience? a lot? only a little?". Or better yet, the game design should have some sort of player representation. I was thinking perhaps a full-on player-done vote for a designer, but I don't really care one way or the other.

[adrix89]

Yes, but who decides when it's time to change things back?

Already proposed a system. A month of trial with a last week polling should be a definitive decision that NO ONE should question. If you fail to get support with that, its on you.

Or maybe something is just controversial and there's many detractors but also many silent supporters.

The silent supports can support by voting at the end of the trial, things need to get more flexible, that means things need to be more active, that means players should get involved it the development of the game.

I mean technically speaking the headcoders are also lead designers

Technically yes, technically.

I happened to have the appropriate file open when HG mentioned he'd prefer if space movement wasn't sanic fast,

I do not know how HG got himself as headcoder, but he does have some track record of some really shitty changes that everyone was against.

I decided to give it a go

And nobody likes it. That feature cannot continue as it is. It will either be reverted or revised. YOU KNOW THIS. You know it is not good and has caused a lot of balance issues. HG did NOT think what those changes would do.

I think much of the general frustration from feedback is because playerbus basically has no real input on design choices and feel very marginalized because of that.

They are marginalized because they have no power and are apathetic. If coders are stubborn and do not listen to them they can do NOTHING.

Instead of very narrow and specific discussions about individual items, I'd love to see more general discussion threads on feedback about the overall direction the game needs to go. Topics like "how dangerous do we want hull breaches to be? deadly? an inconvenience?" or "how much chaos should an average round experience? a lot? only a little?". Or better yet, the game design should have some sort of player representation. I was thinking perhaps a full-on player-done vote for a designer, but I don't really care one way or the other.

I fully endorse this. Even if player polls are out at least we should have this. It's better then to leave it to headcoders who are technically designers.

[Malkevin]

The problem with trials is that it encourages coders to slap dash code together and not put as much effort into making sure their code is bug free and works efficiently, because of the chance that their change will be unpopular and end up being reverted

[dezzmont]

But what may help with some of the hostility is seperating the idea of a coder and the idea of a designer, because they are entirely seperate skill sets. People dedicated to design, to appreciating complex systems, game theory, and player behavior could have no idea how to code but still be more qualified to comment.

We can't have designers, there is no one at the top that is a designer or trusted enough for the position and we are not that organized anyway.
What we should be is flexible let coders change stuff and experiment but be absolutely willing to change it back. Have systems in place for accountability.
Keep what works, throw what doesn't and be back for another shot at it later with something better.

Our best bet is to be iterative.

You are using the term designer wrong. A designer, an individual designer, is not someone who dictates everything that happens. Most design teams make up multiple people talking about a product and figuring out a cohesive direction. A designer doesn't float down from the heavens to dictate everything on a whim, or at least with very little question which is what coders did. A designer thrives on collaberation and discussion because they understand design is a complex tool where every choice is a trade off and pushes the product in a specific direction.

The absolute worst choice, and the one that is the root cause of so much hostility, is treating coders like a special caste of infallible designers who's choices are rarely questioned, which doesn't happen with real qualified designers let alone the 'tech guys' who in real projects don't get a lot of stock in what happens, which makes sense because the skillset is almost entirely different.

You also used iterative wrong in the context of design. Iterative design is simply the process of making changes slowly towards a goal. No sane professional would consider working on a team that conflated iterative with simply making random small changes over and over to see what sticks, because it creates a hot mess of a product loaded feature creep and unclear direction.

Instead of very narrow and specific discussions about individual items, I'd love to see more general discussion threads on feedback about the overall direction the game needs to go. Topics like "how dangerous do we want hull breaches to be? deadly? an inconvenience?" or "how much chaos should an average round experience? a lot? only a little?".

You just described a design process. Design is about talking about product direction and how to get there. A coder may look at hull breeches and see how they affect the server and interact with atmos code, but if you look at them and think "Wow, lets see... a small hull breech is actually easier to set up than a fire, easier to fix, and involves very little interaction from the victim, where as a large one is so overt that it will often force the round to end. If any breach is too strong they risk critting people out of nowhere due to the fact people assume it is generally safe to walk places, simply because someone broke a window out of their line of sight. They shouldn't be strong at all and instead should be focused around deterring movement. Lets tweak the damage rates so that there is very little chance of dying to one unless you sit by it and instead try to aim for 20% damage on any player who runs past a small one. Meanwhile we need to look at how much protection you should need for passing X tiles of space for a large breech. Any ideas?"

Design has the side benefit of reducing the rate of patches and causes more changes to be bundled together, because in general designing something takes longer than physically making it on a project of this scale. That has the positive effect of allowing systems to be instituted rather than features. Even in iterative design you generally need to sometimes hold back content to go with other content for large scale changes. This fails to happen to an embarrassing degree. If your excuse for something working poorly is "It is for a future change" then you are a poor excuse for a coder, let alone a designer, by real world standards. Huge no-no.

The problem with trials is that it encourages coders to slap dash code together and not put as much effort into making sure their code is bug free and works efficiently, because of the chance that their change will be unpopular and end up being reverted

This. Polls are also a really bad choice for this reason in addition to the fact that they would inevitably lead to feature and power creep. A formal design document would allow coders to make bigger changes and features, not smaller ones.

[Steelpoint]

We did used to have a overall design document for what was hopped to be accomplished in a certain year, but it seems no one used it.

The vast majority of changes to the game usually seem to happen on a whim, from what I can tell there is little long term planning when it comes to what people expect to be milestone for a feature or department.

[dezzmont]

We did used to have a overall design document for what was hopped to be accomplished in a certain year, but it seems no one used it.

The vast majority of changes to the game usually seem to happen on a whim, from what I can tell there is little long term planning when it comes to what people expect to be milestone for a feature or department.

That happened for the same reason that a design team would never happen.

Design, like any form of organized, intelligent collaboration, requires bureaucracy and the removal of freedoms. And unless coderbus as a whole has dramatically changed in the past year to be unrecognizable as a whole coders would rather die than give that up. It honestly may have, when I was around coderbus was a disfunctional mess, two of the lead designers legitimately hated each other as people and couldn't talk to each other and one just did not want to ever do anything because of all the drama. Many ascribe that attitude to an egocentric worldview but to me it makes logical sense, because giving up the freedom to make the changes you want means that the game could be pushed into a space you personally think sucks. What doesn't make any sense to me is the volunteer argument. I may work at a soup kitchen once a month for free, but that doesn't mean I get to dictate their overall policy or decide who gets food and who doesn't, and opens you up to design by compromise, or worse, democracy of an uneducated mass.

And that democracy is why polls shouldn't happen. A lot of things should to happen to SS13 that would be radically unpopular. Chemistry (The job, not the mechanic as whole) nerfs for example.

[Malkevin]

Anyway, if you want a process that reduces tears and headaches use the Malkevin method to DevCycle:

1. Come up with an idea or a solution for the problem
2. Think about it for a few days, scratch down some notes
3. Culminate that into a design doc
4. Put that design doc into an Ideas thread, list all changes and explain the goals, aims and why you think this change is for the better
5. Let this run for two weeks (or four, for large changes like game mode overhauls), answer questions and respond to feedback.
6. Get annoyed at people that can't read the fucking thread, or atleast the last two pages and keep autisticing out over the same questions you've already answered multiple times already Revise the design doc.
7. Start coding
8. Test your shit
9. Test your shit some more
10. No really, you've not finished testing yet
11. Submit to github, with full change by change changelog
12. Cry as Coderbus rips your baby apart and realise none of the maintainers or headcoders, or anyone that matters in coderbus, actually bothers reading the forum
13. Wait a couple of weeks for it to finally get merged, whilst dealing with daily merge conflicts
14. Get it merged
15. Wait for slave SoS to get enough time away from his job to rebuild and reboot the server
16. Wait two to three weeks, log onto the server and observe. Listen to the dead chat and see what players are doing with your changes.
17. Start up a feedback thread to curse the names of the vocal few that would moan about the colour hair of the free hooker you got them gather the feedback thats been generated from play testing.
18. Make necessary changes.

For any serious/large changes you're looking at around two to three months time investment.
I spent atleast three months on Cult, thats why I was so annoyed at a couple of people griping and call me 'lazy' for not updating the wiki too.

[dezzmont]

A side effect of the history of entitled attitudes in the coding community I would think, which makes players inherently distrustful of the amount of work you actually did.

It is hard to really get how much work goes into something when a majority of changes are people editing some vars here and there, altering descriptions, or just changing some monkey code and acting like it is some huge labor. Especially because even those tiny changes often are not tested and stuff breaks.

[adrix89]

You are using the term designer wrong. A designer, an individual designer, is not someone who dictates everything that happens. Most design teams make up multiple people talking about a product and figuring out a cohesive direction. A designer doesn't float down from the heavens to dictate everything on a whim, or at least with very little question which is what coders did. A designer thrives on collaberation and discussion because they understand design is a complex tool where every choice is a trade off and pushes the product in a specific direction.

You clearly have no fucking clue what you are talking about. In big teams you have things compartmentalized and specialized, there a level designers, sound designers, mechanics designers, scripters, etc.
They are heads for every department. They are a hireachy, they are authoritative. Yes the heads can hear feedback but they decide, they tell you what to do.
In the case of indies you have as small team with usually one game designer, there could be more like 2-4 but no more.

We are an open source project, we cannot do that, nobody can be lead designer, nobody can tell you what to do simply because you don't have to listen.

You also used iterative wrong in the context of design. Iterative design is simply the process of making changes slowly towards a goal. No sane professional would consider working on a team that conflated iterative with simply making random small changes over and over to see what sticks, because it creates a hot mess of a product loaded feature creep and unclear direction.

Again you have no fucking idea what iterative is. http://en.wikipedia.org/wiki/Iteration

Design, like any form of organized, intelligent collaboration, requires bureaucracy and the removal of freedoms.

You basically want an authoritative system, it will not happen, nobody can be trusted to be good at design and nobody will listen.
All we can do is discuss things and motivate or inspire coders to take on a project.

The problem with trials is that it encourages coders to slap dash code together and not put as much effort into making sure their code is bug free and works efficiently, because of the chance that their change will be unpopular and end up being reverted

Is Gaicom still around? You would never be able to get away with that when he was around.

[Aranclanos]

@adrix89
We're not going to swap to any poll system or change the way the mantainers organize the pull requests and merges, currently it asks for a lot of work and time from the mantainers, I couldn't ask them to do even more considering that it's all volunteer work. Stop suggesting that on this thread please. I do understand the need of you wanting to have a bigger impact on the decisions, but there isn't a good democratic system that couldn't be 'exploited' with politics.

What I'm trying to focus on this thread, is the way of how people communicate and talk about the feedback of the game. So far I'm liking the idea of a non amarillist title on the OP and a template, and later on expecting quality posts who don't insult other people and giving non dead feedback (like 'I do/don't like this' alone). But it's scary to know where is the correct spot, nobody wants to be bioware and claim that all negative feedback is from haters or trolls.
Of course, I have no power on the forums and all of these ideas are just suggestions. But again, give me your thoughts on the issue.

[dezzmont]

Blah blah blah I don't know about design

First of all, I spend most of my days at this point working on multimedia projects as a designer, so you best not do basic google searches to try to come up with an argument and then turn around saying having no idea "what I am fucking talking about" which is what I am pretty sure you did. Because at this point I live design for my masters. I don't want to get deep into fallacious territory but I am, in fact, an authority on the subject of design at this point to anyone who checked my credentials. I am dealing with the dichotomy of designer vs coder in my daily life pretty much constantly and it in no way works like you think, because most people I work with are professionals or fellow students aiming for a masters. I have at this point designed multiple projects for classes that have ended up being used in real world businesses and charities. By all accounts SS13's design philosophy is embarrassing.

On big teams they compartmentalize designs but the lead designer still works with all the departments. Furthermore, there is still a hierarchy. There is a head level designer and level designers.

Designer is no more a leadership position in a multimedia project than writer is a leadership position on a TV show or movie. It works in almost exactly the same way. Designers make proposals for an overall direction, fine tune the details, and then the team as a whole agrees on it. They do not float down from the heavens and just tell coders and programmers what to do out of nowhere because they feel like it.

Most indy games and projects have only one designer because the scope of the team and project is not large enough for more. Space station 13 has, during a bad month, about 40 people working on assets for it. That is an absolutely massive project by modern standards, about as large as many professional game design studios.

You also seem to not know what open source means. It does not mean "Anyone can add anything they want to it" because that would be moronic and would ruin the design of the product. No open source product does this because it just doesn't work. The concept of open source is that the user is a co-developer who has access to the underlying source code to make positive changes in the product. If I edit my firefox browser Mozilla is in no way obligated to push my changes on everyone else, because they have a team of designers who pick good edits and integrate them into the final product.
Also, to quote the wikipedia page you linked

Iteration is the act of repeating a process with the aim of approaching a desired goal, target or result

That last bit is important. There is a goal in iterative design. It is not a bunch of code monkies randomly typing at keyboards to see what sticks because no sane design team works that way. Iterative design is about pushing towards specific goals, not about coders doing whatever they feel like.

You, in fact, can do more than just motivate and inspire people to make changes in the coder system. I have personally worked to get changes pushed through in my day and have forced revisions to occur without the coder in question's consent due to the negative effect it had on design.

Also, way to say someone has no fucking idea what they are talking about in a thread dedicated to curbing hostility. Real classy.

@adrix89
We're not going to swap to any poll system or change the way the mantainers organize the pull requests and merges, currently it asks for a lot of work and time from the mantainers, I couldn't ask them to do even more considering that it's all volunteer work. Stop suggesting that on this thread please. I do understand the need of you wanting to have a bigger impact on the decisions, but there isn't a good democratic system that couldn't be 'exploited' with politics.

What I'm trying to focus on this thread, is the way of how people communicate and talk about the feedback of the game. So far I'm liking the idea of a non amarillist title on the OP and a template, and later on expecting quality posts who don't insult other people and giving non dead feedback (like 'I do/don't like this' alone). But it's scary to know where is the correct spot, nobody wants to be bioware and claim that all negative feedback is from haters or trolls.
Of course, I have no power on the forums and all of these ideas are just suggestions. But again, give me your thoughts on the issue.

Not only is it way too much work for the maintainers but it really isn't a good system for design even if it was effortless. Nerfs would almost never happen and unpopular 'oppressive' jobs like sec or heads would never be buffed. Design is an act of intent and logic, not feels or desire, save for the desire to reach a specific large scale end goal.

[adrix89]

On big teams they compartmentalize designs but the lead designer still works with all the departments. Furthermore, there is still a hierarchy. There is a head level designer and level designers.

Which is what I said. The system is authorial.

Designer is no more a leadership position in a multimedia project than writer is a leadership position on a TV show or movie.

Funny you should mention that because a TV show lives or dies based on the script.

You also seem to not know what open source means. It does not mean "Anyone can add anything they want to it" because that would be moronic and would ruin the design of the product. No open source product does this because it just doesn't work. The concept of open source is that the user is a co-developer who has access to the underlying source code to make positive changes in the product. If I edit my firefox browser Mozilla is in no way obligated to push my changes on everyone else, because they have a team of designers who pick good edits and integrate them into the final product.

Mozilla is a company and is in full control of Firefox. We do not have that leadership.

SS13 had leadership then it was first made, and maybe some servers with their own forked code has their leadership. The only one who could have been the leader is SoS the server owner, but he is not active.
Headcoders might technically have been leaders, but they are more like political moderators. If you want an authority that is your best bet. How much coders trust the headcoders on their leadership depends. For example I have no trust in design decisions from HG.
The rest of the coders do whatever projects they want. And there is plenty of politics and drama to go around. We don't always work together. I dislike Miauw and he dislikes me, our views clash.

That last bit is important. There is a goal in iterative design.

Obviously. But every coder has their own views and goals. Like I said we have no effective leadership to channel it into one. Outside of make that gamemode better or make that system better you cant change much that if it is too fundamental or integrated.

I have personally worked to get changes pushed through in my day and have forced revisions to occur without the coder in question's consent due to the negative effect it had on design.

If you can make coders care about an overall design I am all for it.

Also, way to say someone has no fucking idea what they are talking about in a thread dedicated to curbing hostility. Real classy.

Welcome to coderbus, enjoy your stay, flamewars at 11:00.

[dezzmont]

More bulshit.

I love how you just completely fucking abandoned every original point you made because you realized how wrong you are.

The system is authorial because projects have authority. Coderbus has authority. You acted like there was one designer as an executive role because you clearly thought there was, which was blatantly false.

TV scrips are the most important part of shows, but that doesn't change the fact that being a writer on a TV set isn't a role of singular power, which was my original point to illustrate how design teams generally work.

Coderbus has leadership just like Mozzila does. It is really weak leadership and the head coders probably don't do enough, but it is leadership. As you mentioned there are headcoders. Because, again, you don't know how open source software works. Furthermore there are loose open source projects that still have overall design docs and goals. You don't need a dictator in order to have design.

Every coder having their own goals does not change at all that you didn't know what the fuck iterative design was and assumed it was something that does not work on collaberative projects. You can't have 40 assholes adding random shit to a project based on their own interests and expect a quality result. It doesn't happen. Even when you have people offering services and who want to have room to interpret their projects the way they want to you don't send them off to do random stuff. You give them a design goal. It happens a lot in design for the programmer to function as a designer when the client doesn't have a ton of experience, but the client still tells the designer what he wants. The leadership to channel coders in a direction, in fact, exists. There are people who act as gateways to commit who can halt the project at any time if the coders get too uppity and they have many, many times. This thread was made during such a freeze. Freezes happen when the game's quality dives too hard because of this total coder anarchy you espouse causes too many negative features to be added to the game.

I have, in fact, made coders care about an overall design before. It wasn't even that hard. The project crashed and burnt due to outside forces, mainly a lot of terrible stuff going down in bus and code. Specifically anyone who remembers the idea to change eguns to be exclusive to heads should note that was a collaborative attempt between me and about 6 people to start pushing overall design theory more into bus by using design to change how players look at job roles and departmental interaction. It may sound silly but the context for the change was about a month after code blue was introduced and sec was running roughshod over the station pretty consistently due to the choice made by a coder acting on their own initiative.

Shit ain't hard. Get 5 people in a skype call, look at a problem in the game, look for its underlying causes in a complicated way that views the game as a system rather than a jumble of features, and look for a solution together. This often doesn't happen in coderbus because everyone instead wants to create sexy new features. No one wants to overhaul old systems unless they can add sexy features which is why virology sucked so hard for so long, and why lasers are still sort of garbage.

[adrix89]

Hot air.

Reread my stuff because you missed all the context.
Also just join coderbus and see the situation for yourself.

Shit ain't hard. Get 5 people in a skype call, look at a problem in the game, look for its underlying causes in a complicated way that views the game as a system rather than a jumble of features, and look for a solution together.

Hmm I like the idea of a design roundtable, I am totally stealing it.

Also get back on topic or Aran is going to murder us.

[Jalleo]

The feedback forums is partially caused by the divide between IRC and the forums. Just get a IRC client and have #coderbus up when ya are online and listen to the dicussions. Gameplay discussions are nice to listen to and join in as long as you are civil. There is a lot planned. MrStonedOne does have a stats page for the servers on the things to do but is not done yet. If ya ask MSO and ya know some database stuff you may be able to help get it done sooner.

[Malkevin]

IRC = I have to be there to join the discussion
Forums = I hop into the discussion whenever I get a free moment.

Some of us have actual jobs you know, we can't spend all day idling in an IRC channel

[Aranclanos]

I don't know how to ask it anymore, please stay on topic.

[Hornygranny]

what do you do that you can't idle at work

[paprika]

>not even a thread about the forum in feedback can stay on topic

hilarious

[Malkevin]

what do you do that you can't idle at work

Field computer engineer, I work in schools.
unsurprisingly they filter irc traffic

I literally can not go on to irc during the day

[MisterPerson]

I have mixed feelings. I do feel strongly that turning feedback from a reactive place with mostly complaints about changes into a proactive place with mostly debates about how things should be would be a positive change and greatly reduce the amount of hostility. Nobody else would be the source of a hated change but instead a simple dissenter. And if someone starts spreading hostility simply because someone else disagrees, they were never going to give good feedback anyways. A template could assist in doing that.

On the other hand, while I feel moderation can and has improved the quality of feedback a bit, I have the same fears as Aran about turning into an echo chamber by removing all dissenting opinions simply because of how they're phrased. A required template could also be a subtle bully pulpit to remove unwanted opinions by deleting an undesirable thread while explaining what to do for a favourable one and locking it or even editing it to include the template so it can stay up.

[Cheridan]

[*] Cry as Coderbus rips your baby apart and realise none of the maintainers or headcoders, or anyone that matters in coderbus, actually bothers reading the forum

I hate posting this here as it's fairly unrelated, but I keep seeing posts like this from you and it's something I want to address.

You keep blaming the maintainer team for your frustrations with the project, but your difficulties in contributing with the project lie in your own refusal to cooperate with others. From the very outset you had a "I want to code but I don't want to be a Coder" mentality, and I've personally seen you saying, in deadchat, how you refuse to go into irc for discussion because you hate and don't want to be associated with us. Of course on the forums the reason you gave was "I just don't like chatrooms", so it was eye-opening to see how you really feel.
People who are willing to discuss changes beforehand get the advantage of being able to iron out any issues before they go to the trouble of actually doing it.

Let's take a look at your baby being "ripped apart":
https://github.com/tgstation/-tg-station/pull/3937
Here you can see: me giving you my support for the change, and moderation for overblown comments. Miauw giving information and trying to keep the discussion under control. Anonus making lots of helpful comments.
Giacom's kind of being a jerk as usual but I think his frustration over the many rapid balance changes that were happening to Cult at the time was valid.

And the supporting thread!
https://tgstation13.org/phpBB/viewtopic.php?f=10&t=700

Lots of dissent, mostly from players, presented in a pretty reasonable non-shitstormy manner. Despite the rhetoric to the contrary, we actually *gasp* do listen to the players. When there's a lot of opposition to a balance change like this, the maintainer team is going to find it more difficult to want to merge it.

In this case, both the playerbase and the maintainership is responding to problems they see, which is their right and their responsibility. The variable that's left, is you.

Spoiler:

[iyaerP]

I think that a lot of the vitriol in the feedback forums comes from coders ignoring feedback that they don't like even when the feedback is good quality, because the feedback is negative towards the coder's work. Yes, we understand that coding changes can be a lot of hard work and that criticism of your special snowflake code isn't fun, but when we as the players get responses like this one:

There hasn't been a convincing argument for anything, and I don't feel strongly personally about it one way or the other. I'm not going to do shit just based on volume of feedback if all the feedback isn't useful. It's literally just been 8 pages of "it's shit" (why?), "I can't escape the permabrig" (good, you shouldn't be able to), "it makes leaving the station suck" (good, stay on the station)", "it doesn't do what it was supposed to do" (not a reason to change or stay, doesn't matter) and "it's unrealistic" (don't care, realism is an awful reason to make changes). Short of a decree from a headcoder, the only other things I plan on doing on this are making jetpacking about the speed it was and applying the space-related slowdown effects to all mobs.

for an issue that is as black and white as how horrible the space speed changes were.

If coders don't want to get vitriol in their feedback, then they should not antagonize the people who provide feedback. Furthermore, there needs to be a requirement for maintenance of code. If you broke something, you are under obligation to fix it. The thread I quoted from, the space speed thread, even has multiple posts of Mrperson acknowledging that his code broke several different roles and mobs, didn't fix the intended issue, and is only causing problems with gameplay, but refusing to fix it regardless.

That kind of attitude more than any other factor is why the playerbase has such antipathy towards the coderbase.

Look at how everyone regards paparika. Lots of the changes he makes are good and improve the game, but any time he is confronted about any kind of bad idea or mistake, or even just suggestions about how to improve something, he immediately starts shit-flinging and troll posting. As a result, his reputation in the playerbase is the worst of the coderbus because he so perfectly encapsulates what everyone hates about it: an entitled attitude, a refusal to acknowledge feedback, and an ego the size of the moon.

I guess the point I am trying to make here is that if you as the coders want us as the players to stop being rage-filled hate-mongers, then not dismissing us out of hand every time we speak up would go a long way towards building that trust. People aren't loud and angry because we get off on heartburn. We are loud and angry because civil and rational discourse has utterly failed us almost every single time we bring up an issue.

[dezzmont]

Also, don't be so quick to point out coding is a hobby for you and thus should be fun. I voulenter at a soup kitchen as a hobby because it is fulfilling. I don't freak out because I am not allowed to do whatever the fuck I want just because it is a hobby.

It is a volunteer position, but it is a position that grants privileges. That means it should also come with responsibility, because coders are, very strictly speaking, not all that necessary in the grand scheme. It would suck if they were not around because they add cool things, but they are a luxury, not a necessity.

Mandated maintenance code of your own work would be a good start. Your change should be reverted and you should be blacklisted from future changes if you constantly add stuff that breaks things and don't try to fix it. Hell, your change should probably be reverted while you fix it if the bug is major. That is what real code teams do who want to have any reputation in the professional world, and while I doubt anyone cares about that it is still a great practice to emulate because it inevitably raises the quality of your project to have a strong bugfixing policy. If you don't fix it because you don't want to be assed, no one else is gunna feel assed to constantly clean up after your messes either.

https://tgstation13.org/phpBB/viewtopic.php?f=10&t=700

This thread is gold and shows exactly what design minded people can do. Especially when Oldman started to explore a really high end design concept when he took apart what murderbonnering is, focusing less on the action and more on the ramifications for the players of the game. Behaviors should be judged based on their results, which is why the code discourages traitor murder boners but encourages it in cult.

[Miauw]

For major bugs there's little point in reverting the change usually, since they're usually not noticed before the code goes live, the fix PRs are usually merged posthaste etc.
However, I do remember a particular major bug that hasnt been fixed...

[dezzmont]

For major bugs there's little point in reverting the change usually, since they're usually not noticed before the code goes live, the fix PRs are usually merged posthaste etc.
However, I do remember a particular major bug that hasnt been fixed...

There have been major bugs just living in the code for ages at times. Major in code isn't always the same as major in the game. I know that diagonals were buggy as hell yet still were pushed out, and viruses used to be incurable because they moved through walls and you never got immunity, so quarantines and cures didn't work, and that was around forever.

Besides, it is a good policy to have regardless because it encourages testing and maintenance. If you don't value the craftsmanship behind your change then you flat out don't deserve to work with code on any project. A virus bug making everyone have the flu sitting around for a year to the annoyance of all is the least of what can happen with code if you don't give a crap and just endlessly push stuff through. In most professional settings you would be fired and you would eventually build up a reputation that prevents you from working in any high end job with any responsibility because bugs are a huge deal in software development.

[fleure]

Mandated maintenance code of your own work would be a good start. Your change should be reverted and you should be blacklisted from future changes if you constantly add stuff that breaks things and don't try to fix it. Hell, your change should probably be reverted while you fix it if the bug is major. That is what real code teams do who want to have any reputation in the professional world, and while I doubt anyone cares about that it is still a great practice to emulate because it inevitably raises the quality of your project to have a strong bugfixing policy. If you don't fix it because you don't want to be assed, no one else is gunna feel assed to constantly clean up after your messes either.

This has been discussed before, and I am totally behind the idea. I am not sure why this hasn't been implemented already, really.

[dezzmont]

Mandated maintenance code of your own work would be a good start. Your change should be reverted and you should be blacklisted from future changes if you constantly add stuff that breaks things and don't try to fix it. Hell, your change should probably be reverted while you fix it if the bug is major. That is what real code teams do who want to have any reputation in the professional world, and while I doubt anyone cares about that it is still a great practice to emulate because it inevitably raises the quality of your project to have a strong bugfixing policy. If you don't fix it because you don't want to be assed, no one else is gunna feel assed to constantly clean up after your messes either.

This has been discussed before, and I am totally behind the idea. I am not sure why this hasn't been implemented already, really.

Some people in life miss out on the fact that they are ultimately not really more important than other people, meaning other people deserve to be treated in the way you want to be treated. It is a case of selfish ego-centrism and there is no real defense for being allowed to dump your messes on other people.

Most defenses of the idea of leaving bugs in comes down to a lack of moral character and personal pride. If it is too much work for your busy busy day, it means you shouldn't be coding. If you feel they are unimportant, you are wrong, as you just reduced the overall code quality for every future coder dealing with your work. If you think it is distracting to your next super important magnum opus then you ultimately ego-maniacal and feel that other people should serve you by fixing your code, and shouldn't be allowed near a collaboration ever.

Ignoring bugs as they happen is a deadly sin in the development cycle because it resonates throughout the future of the project and makes everyone's life tougher. It is up there with not annotating your code or putting in 'pre-patches' for future changes without having a very strict timetable for the future change and a very compelling reason for it. It is something that should never ever happen. Not testing and letting something slip by sucks, but mistakes happen. But what is completely unacceptable in life is pushing your mistakes onto others for no damn good reason.

The inability of some people to clean their code is what leads to code freezes. Pretending that it is a minor issue probably means that you are part of the problem that is directly responsible for forcing everyone to stop working on something cool as they wait for anyone to nut up and start fixing the shovelware crap you made.

There ideally should be 0 bugs, realistically a small number cropping up after any change that quickly go away, not not 348 where only one and a half of fourteen pages are less than two weeks old.

[whodaloo]

This is a topic about hostile feedback, not the fucking moral fiber of our coders. Good god.

[dezzmont]

This is a topic about hostile feedback, not the fucking moral fiber of our coders. Good god.

Related topic. Or at least the perceived lack of fiber ties into a lot of the antagonism, which I personally feel comes down to a highly unprofessional attitude generally held by the coders.

Many people feel like they hold themselves to no standards, hence most feedback is very personal. If you want people to talk about the issues and not you, you need to not be the issue yourself.

Furthermore this thread wasn't just about hostile feedback, but about policy as well. The opening post is asking a question about re-organizing and making coder-player relations more formal. Pointing out there are very glaring organizational flaws in coderbus is completely relevant to that discussion. Forget about developers vs coders, which is relevant to a feedback meta-discussion. A lot of that is opinion based, I am a designer and I am design biased. Talking about an inability to enforce quality code resulting in systemic mistrust and hostility towards the code team is relevant to feedback forums hostility, and even if the theory I have isn't correct these are problems that need to be adressed.

[cedarbridge]

From the very outset you had a "I want to code but I don't want to be a Coder" mentality

When "be(ing) a coder carries its own stigma of being a closed off member of a club that has expressed disinterest in the playerbase and player feedback in the past, I can understand why somebody would take this position. Nobody wants to be "a politician" but many want a direct say in government and want the ability to make changes in the world. Attacking him for not wanting to join your club as though that were some sort of sin is a pretty good example of why many refuse to join the bus or even touch the coding project.

[whodaloo]

This is a topic about hostile feedback, not the fucking moral fiber of our coders. Good god.

Related topic. Or at least the perceived lack of fiber ties into a lot of the antagonism, which I personally feel comes down to a highly unprofessional attitude generally held by the coders.

Many people feel like they hold themselves to no standards, hence most feedback is very personal. If you want people to talk about the issues and not you, you need to not be the issue yourself.

Furthermore this thread wasn't just about hostile feedback, but about policy as well. The opening post is asking a question about re-organizing and making coder-player relations more formal. Pointing out there are very glaring organizational flaws in coderbus is completely relevant to that discussion. Forget about developers vs coders, which is relevant to a feedback meta-discussion. A lot of that is opinion based, I am a designer and I am design biased. Talking about an inability to enforce quality code resulting in systemic mistrust and hostility towards the code team is relevant to feedback forums hostility, and even if the theory I have isn't correct these are problems that need to be adressed.

I disagree with the assertion that the coders are at fault for the attacks on them. I think there's a boogieman mentality on TGstation that's to blame for a lot of the negative feedback on these forums. I agree that coderbus could probably use some ground rules, or at the very least coders could use some people skills, but saying that coders are the 'issue' in question re:Hostility is something I disagree with quite heavily. All you have to do is look back at the topic- on the first page, stuff like

So... You can dish it out, but you can't take it.

Hyperbole? Thats literally a paraphrase of a Paprika post.

Aren't problems with the coders in particular, but rather the community's view of coderbus in particular. I think rather than jumping on the codebus's back for perceived moral failings, some sort of zero-tolerance policy for personal attacks should be put in place, at least in regards to feedback threads. I'm sure there are people out there who immediately go >hugbox, but I'm not suggesting stomping down on criticism in general. "This change sucks dick, because x y z" is a-okay, "This change sucks dick because pap/aran/whoever made it, ban he" fucking isn't. This policy would obviously go both ways- the codebus is no stranger to sniping people they think are shitters, but if they can back up their arguments I don't see any reason why their input shouldn't be taken.

tl;dr coders are friends not food

[dezzmont]

This is a topic about hostile feedback, not the fucking moral fiber of our coders. Good god.

Related topic. Or at least the perceived lack of fiber ties into a lot of the antagonism, which I personally feel comes down to a highly unprofessional attitude generally held by the coders.

Many people feel like they hold themselves to no standards, hence most feedback is very personal. If you want people to talk about the issues and not you, you need to not be the issue yourself.

Furthermore this thread wasn't just about hostile feedback, but about policy as well. The opening post is asking a question about re-organizing and making coder-player relations more formal. Pointing out there are very glaring organizational flaws in coderbus is completely relevant to that discussion. Forget about developers vs coders, which is relevant to a feedback meta-discussion. A lot of that is opinion based, I am a designer and I am design biased. Talking about an inability to enforce quality code resulting in systemic mistrust and hostility towards the code team is relevant to feedback forums hostility, and even if the theory I have isn't correct these are problems that need to be adressed.

I disagree with the assertion that the coders are at fault for the attacks on them. I think there's a boogieman mentality on TGstation that's to blame for a lot of the negative feedback on these forums. I agree that coderbus could probably use some ground rules, or at the very least coders could use some people skills, but saying that coders are the 'issue' in question re:Hostility is something I disagree with quite heavily. All you have to do is look back at the topic- on the first page, stuff like

So... You can dish it out, but you can't take it.

Hyperbole? Thats literally a paraphrase of a Paprika post.

Aren't problems with the coders in particular, but rather the community's view of coderbus in particular. I think rather than jumping on the codebus's back for perceived moral failings, some sort of zero-tolerance policy for personal attacks should be put in place, at least in regards to feedback threads. I'm sure there are people out there who immediately go >kickin' rad place to be, but I'm not suggesting stomping down on criticism in general. "This change sucks dick, because x y z" is a-okay, "This change sucks dick because pap/aran/whoever made it, ban he" fucking isn't. This policy would obviously go both ways- the codebus is no stranger to sniping people they think are shitters, but if they can back up their arguments I don't see any reason why their input shouldn't be taken.

tl;dr coders are friends not food

It is such a given that people making baseless personal attacks should be taken seriously. Saying we shouldn't tolerate baseless personal attacks is obvious, but the problem is that many coders take their changes very personally, and in design attacking motivation is an important aspect of discussing changes. The cult change thread for example had people pointing out that the changes were made from a point of extreme ignorance. It got personal, and in some ways was an attack, but was still relevant. Pointing out someone doesn't understand what they are doing and being able to back that up is a very powerful argument. As long as people were not saying "God you are dumb" its kosher. Blatant personal attacks don't seem to even be happening from what I can see scrolling through the first page of feedback. So either you are talking about stuff off the first page or feel like things going on now that are rather benign are personal.

In the PR world, an image problem where you are a boogyman is always your fault. Every time. Doesn't matter if the reputation is deserved or not, you earn a reputation over time.

And I have worked very extensively with coders. I have had to stop personal harassment going on off IRC and off the forums, working in the back end of skype. There are still people here who have told me directly that they dislike the players, think they are idiots, and have no real right to an opinion. Saying anyone is blameless in having an image problem is always always incorrect, but some coders work especially hard to earn it for the group.

Saying we shouldn't tolerate baseless personal attacks is obvious, but the problem is that many coders take their changes very personally, and in design attacking motivation is an important aspect of discussing changes. The cult change thread for example had people pointing out that the changes were made from a point of extreme ignorance. It got personal, and in some ways was an attack, but was still relevant.

Policy issues exasperate personal failings of people. Players don't like how coders historically have talked down to them, and they have talked down to them publicly and in private. And when a coder blatantly shows a lack of personal work ethic by implementing changes that are self admittedly not finished, or by ignoring bugs in a product, it pisses people off against all coders.

I know for a fact things are not as bad as they used to be in my day. It is downright impossible. A lot of my opinions are colored by having to deal with Pinku going on paranoid rants against conspiracybus, or Erro being fundamentally unable to work with Muskets. These people left a legacy that you all have been saddled with and need to overcome.

But I know a lot of coders who are still about who are problematic and not at all good at collaboration, more importantly these people got so problematic because of systemic flaws in coderbus in terms of public relations and orginization.

The TL;DR: is that while coders may be friends, not food, you can't start fixing PR problems within bus until you fix glaring organizational flaws that everyone can see. No one is going to trust you when the system is so easy to abuse and people have been shown willing to abuse it. It isn't saying coders are evil, you guys just have legit problems you need to work out if you want to make your lives better.

From the very outset you had a "I want to code but I don't want to be a Coder" mentality

When "be(ing) a coder carries its own stigma of being a closed off member of a club that has expressed disinterest in the playerbase and player feedback in the past, I can understand why somebody would take this position. Nobody wants to be "a politician" but many want a direct say in government and want the ability to make changes in the world. Attacking him for not wanting to join your club as though that were some sort of sin is a pretty good example of why many refuse to join the bus or even touch the coding project.

Being a coder is a thing. It has always been a thing, and pretending it is not is disingenuous. Coders treat each other differently, are treated differently by players, and are very certainly treated differently by the admins. They have a large amount of influence on how the game develops, far more than other players even though supposedly they simply code and don't decide on actual changes. They vary in how official they are, in my day every coder got admin as a matter of fact, was on a master list, and had commit, where as now commit was slashed very heavily. Now they are a looser group, but they are a group, it is why they are talked about in in-group out-group terms. You don't need to be an official thing to be a thing. America doesn't have a class system but it totally has a class system for example.

We can talk about the ideal of them being a not-thing, but they are a thing. It is exactly like claiming to 'not be a politician.' It is blatantly false and you can't even make progress on fixing problems if you refuse to believe they are there. If you believe an official coder status is a problem. Which I honestly don't think is a problem save for problems in coderbus.

[Incomptinence]

Segregating bug reports of from the forums doesn't help. Bug reports are probably the most helpful form of feedback but we don't really keep a good visible record of them (that isn't buried in git) so they might as be swept under a rug.

[cedarbridge]

From the very outset you had a "I want to code but I don't want to be a Coder" mentality

When "be(ing) a coder carries its own stigma of being a closed off member of a club that has expressed disinterest in the playerbase and player feedback in the past, I can understand why somebody would take this position. Nobody wants to be "a politician" but many want a direct say in government and want the ability to make changes in the world. Attacking him for not wanting to join your club as though that were some sort of sin is a pretty good example of why many refuse to join the bus or even touch the coding project.

Being a coder is a thing. It has always been a thing, and pretending it is not is disingenuous. Coders treat each other differently, are treated differently by players, and are very certainly treated differently by the admins. They have a large amount of influence on how the game develops, far more than other players even though supposedly they simply code and don't decide on actual changes. They vary in how official they are, in my day every coder got admin as a matter of fact, was on a master list, and had commit, where as now commit was slashed very heavily. Now they are a looser group, but they are a group, it is why they are talked about in in-group out-group terms. You don't need to be an official thing to be a thing. America doesn't have a class system but it totally has a class system for example.

We can talk about the ideal of them being a not-thing, but they are a thing. It is exactly like claiming to 'not be a politician.' It is blatantly false and you can't even make progress on fixing problems if you refuse to believe they are there. If you believe an official coder status is a problem. Which I honestly don't think is a problem save for problems in coderbus.

The question isn't if coders should cease to be, but rather that if they want to attack people for not taking on a title, they should do something to reduce or remove the stigma associated with that title. Attacking somebody for not jumping onboard is part of why people don't want to do so. Its not a question of "why don't people want to be coders" and more "why don't people want to be associated with the title 'coder'?"

[Hornygranny]

Unfortunately for dezzmont, the nature of the project is such that it must be worked on by coders rather than PR specialists. I encourage you to participate directly rather than pontificate on the forums. This thread has officially jumped the shark.

[Hornygranny]

I forgot to address adrix89's question about voting: this will never happen under my reign of terror.