Communication

[Peter]

[...]
The only advantage is the wiki, but we could use a MediaWiki somewhere. Tortoise svn can be used for the source management.
[...]
But I'm not blaming you for that. As far as I know it was Peter who insisted the change to trac without discussing it first, and yet it's ironic how he has the right to criticise.

Actually no. Moving to Trac was a well thought-over decision and you're ignoring a number of things here. Las Venturas Playground is a huge community and is an interesting target for hackers, all our servers are under brute force attacks on a daily basis, MySQL can barely run on the default port without being flooded with login attempts and a frequent DDoS attack isn't a rarity either. Yet we, or more strictly said I, have a large responsibility over the user information. What exactly do you think is going to happen if the full database including names, e-mail addresses and passwords, albeit hashed it published? It won't be much longer, I think even this year, that an investigation to Las Venturas Playground's security- and protocols will be started by privacy orginizations when we breach the 100 thousand user milestone. I can assure you most of these users don't use seperate passwords for their e-mail addresses or other forums- and accounts, I do not want to be responsible for the loss of tens of thousands e-mail addresses and msn accounts.

Security is becoming an increasing priority. Lately several hack attemts have been taken against LVP, two of which succeeded. Due to rapid and proper responses by the Management the only damage was the loss of three passwords, all of which have been changed. This is not a game anymore, serious people with serious abilities are coming after the information we store. This simply asks for a number of measures to be taken;

• Increase security where possible
  Most important ports on our servers have been replaced with alternative ports, all important passwords are long enough to ensure they do not show up in any hash table and our firewalls get tightened every week. Vendor software we use gets updated as often as possible to minimize the risks of unwanted access through any outdated system. In terms of security Trac is far superior to Mantis, it protects against loads of attacks, has advanced access rules and incorporates your Subversion access with your Trac access.
  
• Spread the risk
  Las Venturas Playground used to run on one server, now we use four. One for the website, one for the game server, one for development & trac and one for backups. The backup server is at an unknown location and the IP address is not known to any of you, yet every night every sever gets backupped to it. By having things on seperate servers the chances of the entire Community being unavailable are quite low, future plans include using multiple webservers and a load balancer, automated text-messages to the Management's mobile phones when something is wrong (or even odd) and possibly enforcing secured connections on IRC to enter our crew channels.
  
• Ease of working
  Trac integrates Subversion with the interwebs, tickets, modifications, milestones and all can be exactly integrated with the source code. Committing a bugfix allows you to include the bug-number (#2423 for example) which Trac will automatically update. Yes, the Wiki syntax is different, tickets work slightly different but the solution is far more mature than mantis. There is a reason other parties like Webkit, ICU and BOINC use it.
  

Let's face it, Las Venturas Playground's development team is a mess. It's a large community which will be growing even stronger after next month, gamemode updates will become essential and we need to mature these processes. Next to that, there is a large chance many of you will end up in the IT industry and having knowledge like proper project management, following policies and working in a team is a major head start.

Sorry but that isn't going to work. Do you not think I haven't tried that? In the past I have constanty asked other developers about features in IRC, added numerous notes to tickets on the mantis, and made topics in these forums - but people rarely paid attention or acknowledged this. The only person that I used to have a good full on discussion about features with was tomozj. When I get into something, I'm a really active developer. I like to develop things without having to wait till the next day or week until someone is active.

We're currently a team of four people remember. Sure there are other developers like [Griffin]* Felle and Pugwipe, but they aren't very active and haven't done much for LVP.

Excuse me? By saying this you're pretty much implying you want developers to extort the right of exclusivity over the development of Las Venturas Playground. This way only they can decide where things are going, which is not how LVP works. You probably have the image that the Management does nothing at all, yet I also believe this post contains a shitload of new information to you already. Working the way you are proposing, simply thinking of a feature and implementing it straight ahead, is nothing else than a lack of professionality. Allow me to emphasise;

Imagine that you have an awesome idea to implement a new minigame handler. Without discussing it you implement it and it works perfectly. However, a week later Fireburn wants to add a new minigame type and a huge part of the handler has to be rewritten, all minigames no longer are compatible and have to be changed as well. A team stands or breaks by the way they communicate; rather than thinking now, think ahead. If you have an idea for a feature, post a topic on the forums explaining it, allowing other people to respond. After 48 hours or so you read the replies and either implement it or not. All developers have great idea's and can comment on things, your minigame handler might be lacking a number of functions, what's wrong in allowing them to improve your features before you even have implemented them?

Furthermore I'd say it's fairly ironic you're saying moving to Trac should be discussed while gamemode changes or features can be implemented straight on. By the way, Trac also sends e-mails to those interested or coöperating in a ticket, so adding notes and all is much easier and clearer.

Some changes need to be made the way I see it. Firstly I would like to see the dev channel only open to developers and head management and feature's strictly decided by developers to. Fair enough it's okay making a suggestion, but people shouldn't be able to make feature tickets and expect us to do it*.

Simply said, the Management outranks the Development Team. They have the right to be around wherever they want to be. Seeing you are in the Management IRC Channel you have that right as well. The Lead Developers are responsibly for managing LVP's progress, functionalities and future in the future, in corporation with the Management. Why? I don't see you working on any website, advertention campaign, general image or complaint filed by any random user. Features are nice, however let's be honest, scaling this gamemode to be able to manage 200, or possibly even 500 users is way over your head, especially in terms of storing the data. Without MrBondt, Badeend, Pugwipe and myself we'd still be using file storage, slow, non-indexed MySQL tables or various single-points of failures. Without people like Nakebod, estroe and Dennis the gamemode would have a lot less vehicles, jokes or properties. Yet none of these persons is listed as a developer.

Secondly I would like some changes to the way people report tickets to. Only developers should decide and write feature tickets, anyone else should just do bug reports.

Partitially agreed, I believe the Management should maintain their right to create feature tickets. Especially now things like the website will be moving to Subversion as well it's going to become more complex, however, eventually is should lead to a larger, smoother development team. Right now I'd say Developers and the Management, while the Lead Developers have to accept every feature before it gets implemented (e.g. everything has to be discussed for at least 24-48 hours).

Thirdly I think developers should assign their own tickets to themselves. If a developer writes a ticket, they should do it, and not expect others to do it.

Disagreed. Especially in terms of bugs this simply doesn't work, everyone should find a good balance between features and bugfixing. Developing is not only taking the nice parts, every one of you is bright enough to find that balance, in discussion with the Lead Developers if required.

Finally I'd like a proper beta team. Not the whole crew as beta testers like it was insisted upon last time (yeah, when it was my project and I was forced into decisions again) but instead people from the community. Currently there are about 30 people in .beta. The only good beta testers have been Chillosophy, Joe, estroe, Pugwipe, Twilight and Maka.

Agreed, I don't know why these people are around at all. I don't think crew should have the right to be betateam-members by default, however, I also believe there should be a Betateam Leader who is not a crewmember or developer.

P.S I don't mean to be disrespectful in the slightest, just incase anyone takes this the wrong way. I do understand that developing is a voluntary position and people can't always guarantee work.

Don't get me wrong, I've been rather blunt towards the development team lately. Changes must occur, will occur (9-20...) and I believe they should occur in the right way. Currently we don't have a team and the only way that's going to change is by implementing better coordination. What do you prefer, having to think about what to implement or having a large list of things to choose from, every single item of which has been thought out properly. Yes, it means that the time between thinking about- and implementing a feature increases from no time to 24-48 hours, however, it will improve the quality of the LVP Code majorly.

You guys deserve to be the best around in the community and I truly believe you can be the best, however, until we get there a rough road may be ahead. A road filled with changes and things you will be disagreeing with, however, also a road of oppertunities. Trust me when I say you will learn loads of the changes which are going to happen, and eventually you might even agree and see the purpose of them.