Communication

[Wesley]

Dear developers,

When working in a team communication is very important. At the moment we are not really working as a team, we do not know who is doing what, it's just some individuals working on the same code. This is something we must improve.

Some things we are going to want to change is the way we handle tickets. We no longer want to use Mantis, but use Trac instead. This allows us to assign tickets to different milestones so we have a better overview of coming releases. It is very important that you create a ticket for everything you do. Another thing that is important, is describing your commits on SVN so we can see what has been added in a certain revision.

We'd also like there to be more discussion before changing important things or adding features. Ask other developers in the #lvp.dev IRC channel, post here on the forusm or have them comment on the ticket at Trac. This way we ensure that the things we do are supported by most of us, and maybe another developer has an idea to slightly improve your feature or ticket, this way we can develop even better features.

These are just some things that Fireburn and me have discussed, but we also want to know what you think. What do you think would help us improve the communication inside our team? What do you think of the things we have thought of? Please let us know. And please don't wait too long, we'd like to have your response within a week so we can write a policy describing the things we have agreed on on this area. After this we will post this document and allow for more comments if necesarry.

Thanks for reading,
Joppe 'Fireburn' Arnold
Wesley Lancel

[Wesley]

Another suggestion I have is to start adding a small description to the header that each file has in the new PreCompiler branch. This description should contain the use of that specific file in a few lines. This will help quickly recognising what the file is used for. These descriptions should also be added to the new files that are already in the PreCompiler branch in my opinion.

[Jay]

When working in a team communication is very important.

We no longer want to use Mantis, but use Trac instead.

Sorry but that made me laugh. Your saying that communication is important - and yet your going ahead and changing the way we do tickets without "communicating" with us first and asking how we feel about using trac. Mantis isn't that bad - at first me and tomozj both wanted to use trac, but Badeend inisted that we must use Mantis, which I was pissed off about for days, because at the time it was my project and I was being forced into using mantis. I felt like quitting.

But now my attitude has changed. I prefer mantis - It has features similar as trac, so I don't see why we can't use that. It also has a better priority system and we can assign our tickets to a different status - e.g, if we require feedback, if a bug has been acknowledged or confirmed, etc. It is a lot easier to use to.
The only advantage is the wiki, but we could use a MediaWiki somewhere. Tortoise svn can be used for the source management.

Perhaps discussing changes before making them is one of the ways you could improve communication. 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.

We'd also like there to be more discussion before changing important things or adding features. Ask other developers in the #lvp.dev IRC channel, post here on the forusm or have them comment on the ticket at Trac.

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.

* Although I must say [Griffin] has made a few commits lately and has indicated he is working on an anticheat

Another suggestion I have is to start adding a small description to the header that each file has in the new PreCompiler branch.

We do that already though. (Well, I do anyway )



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*.

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.

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.

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.



* That ticket was only an example of what I presume was made without any discussion within the development team. I'm not certain on this because it was made at a time when I was not a 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.

[Wesley]

Sorry but that made me laugh. Your saying that communication is important - and yet your going ahead and changing the way we do tickets without "communicating" with us first and asking how we feel about using trac. Mantis isn't that bad - at first me and tomozj both wanted to use trac, but Badeend inisted that we must use Mantis, which I was pissed off about for days, because at the time it was my project and I was being forced into using mantis. I felt like quitting.

But now my attitude has changed. I prefer mantis - It has similar Roadmap and Milestone features as trac, so I don't see why we can't use that. It also has a better priority system and we can assign our tickets to a different status - e.g, if we require feedback, if a bug has been acknowledged or confirmed, etc. It is a lot easier to use to.
The only advantage is the wiki, but we could use a MediaWiki somewhere.

Perhaps discussing changes before making them is one of the ways you could improve communication.

Mind that all these are plans, we're not posting them here for nothing. We want your opinions, nothing has actually been changed yet. Though I must admit that I think it'll be necesarry to use Trac. It's features are way better, and we want to combine as much as possible in 1 solution. Trac has all this, tickets, wiki, source management. We also want to start using milestones and roadmaps in the future more, which Trac is great for. Still, we're posting this here to ask you, we want to hear what everybody thinks, not just us two. Therefor I'd like Matthias, Felle, [Griffin]  and the others to reply too, so we can take a good decision.

I'll reply to the rest of your ticket later.

[Matthias]

I like Mantis a lot, and it's easy to use. Since I never worked with trac, I have no idea what functions it contains. I'd love to keep working with Mantis, but as Wesley said, Trac has all the features that we need.

[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.

[Jay]

I've just done a little research on google and I couldn't see anything indicating any security issues with Mantis or anything to show that trac is more secure. Security measures do need to improve, but I fail to see how changing to trac is one of the ways. Las Venturas Playground is a large community indeed, but let's compare it to another community which is much larger: Multi Theft Auto. MTA have been using Mantis ever since it's development process began - you can check the dates of the very first tickets as evidence on http://bugs.mtasa.com. I'm sure they are a much more popular target for hackers compared to LVP. Infact you only have to google the words "MTA hacks" and you'll come across a large number of websites, and yet as far as mantis is concerned, they've never publicly stated any issues they've had with it and have never stopped using it for any reasons. There database must contain way more entries than 100,000 - there are more people than that registered on their community website alone. I'm interested in seeing your source on how trac is more secure.

• 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.
  

Mantis has better priority and ticket management. Roadmaps and Milestones are possible in Mantis along with a nice grouping system for bugs, features, etc, allowing you to view and organise your tickets a lot better. I don't see a need for trac to handle source modifications anyway, we can do that client side with tortoise subversion just fine.

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.

Obviously I'm not proposing we continue work like this because it just won't work. Everytime I've done a new feature I've added a ticket to go along with it. I've also tried discussing it on IRC and showed the ticket's URL with it, but nobody has ever commented or discussed it. I can't help it if people don't wish to share opinions - by doing this I just presume people have no objection to a new feature.

Anyway, I agree to your proposal of posting at the forums and waiting 2 days before going ahead with features. I can see [Griffin] has to because he's already made a topic.

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.

Fair enough. Although I kind of meant point two with this quote (hey it was late) about management writing feature tickets and deciding on some features. Some changes need making to the CSI board. The Open for discussion section should be renamed to Approved and management shouldn't be allowed to move topics to it without discussing it with a developer first.

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.

I actually meant features by this. I just wouldn't like to see things become a mess again. The Mantis is currently full of unassigned tickets that other developers have wrote but nobody else is willing to do it. Perhaps now that features are going to be properly discussed, this issue will no longer occur because we will be able to discuss who's doing what as well.

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.

This needs to have a high priority at the moment in my opinion - after all it's the beta team that finds the bugs. Some rules need setting up. Perhaps we could develop in beta version stages, each beta version containing a changelog for beta testers to go ingame and test.





P.S
If you write another big ass reply I'm going to bite your head off.

[Wesley]

A small summary of what was discussed in this topic;

Communication

As communication is the key to a successful team, it is important to have a policy on this topic too. After some discussion of the forums, this will be some final guidelines that we would like to stick to. These guidelines include how to work with trac, how to discuss features and tweaks with fellow developers before actually creating them, and other things related to the internal communication of the Las Venturas Playground Development Team.

Since a few weeks we have been using trac, for a number of things, being tickets, source management and as a wiki. In the future every ticket should be reported on trac. These tickets should be assigned to different milestones and versions. Versions are ‘Las Venturas Playground 2.91’, or ‘3.0’, milestones are points within these versions at which a number of things need to be done. These milestones are ‘Alpha 1’ etc. Something that has changed since Mantis, is that players and crewmembers no longer will be able to report bugs directly to our system. The old system of the special forum board will be brought back for this purpose.

Something else that is already changing is the communication with fellow developers and people from the Management, prior to creating new features, tweaking things or fixing bugs. Especially with features it is important to create a topic in the board specially created for this purpose, and allow others to reply there and have a say about what you want to do. Preferably you wait for at least 48 hours before starting developing. Final decision and responsibility lies with the lead developers. Starting such a topic is of course not necesarry for small bugs fixes to bugs that have been reported.

Please reply with any comments or suggestions that you have. If no replies are made, this is final.