[Development] Dev needs to be optimised

[Conn]

Point A

Looking at the sheer amount of times features of the "correct git flow" (for example LFS) simply fail to work just proves that sometimes you need to log in with a shell and pull changes forcefully. It is also ironic how for years developers, who invest their freetime into trying to make FL better, always have to fight against distrust, while apparently developers who actually abused their powers to great extent still get a 2nd chance in one of the highest positions. It just doesn't quite make sense to me.

The initial problems with git lfs was it being setup by someone who was new to LFS and didn't have the required experience to set this up, being one of the reasons why server maintenance has been assigned to DevOps.

2nd chances exist to show that was you did was wrong and regret your actions. But still have the interest of helping my community with the skills and knowledge you possess. Same for me. It's not like I didn't had to earn this trust again.

Originally I began the integration of Git LFS in order to get a system set up quickly, as developers were stuck waiting around due to access to FTP being taken following a decision made by management & yourself. This decision was problematic due to there being no timely plan in place for dev access, which was necessary for multiple updates at the time. This lack of foresight has been shown multiple times, I will cover this further later.
LFS had some initial issues due to permissions, which I was working to fix, with the help of yourself. Admittedly, I was coming in with little experience with Git LFS, hence I was communicating with both you and Ed to ensure that stuff was done correctly when reworking to fix issues. I'd have happily stepped aside and allowed you to set this up, except time and time again it has shown that stuff isn't done in a timely manner, when it really needs to be.
The nature of the development on this community is sporadic, it happens when people get motivation to work on stuff, and if they're forced to climb over roadblocks the whole way there, they will not work on stuff.

My real problem comes with the absolutely embarrassing handling of this from yourself. This is best shown with the communications that we had, following you answering some questions that helped me sort out the issue:


Context: I was working on the revised script following the information given to me, and at the time, was around 6 hours in to doing so. Suddenly, the server randomly restarted, following by me losing access to my SSH twice. As it turns out, you removed my access with no right to do so.

The script that I was revising was originally written around a year ago, as a temporary solution to the Git auto-deployment system, which you assured was a top priority for you. As it turns out, that script had a potential vulnerability, which I accept, and was working to improve in the recent revision. Instead of speaking to me about said vulnerability, you spoke straight to management, working behind my back, at no point thinking it may be a good idea to speak to me, to work in a team, and to help resolve said issues. 

Fast forward to 27/03, where this is summed up quite nicely. 



You continue to show a refusal to work in a team, to work behind our backs for no good reason. I believe I speak for other developers when I say that the attitude that you have displayed towards the development team is nothing short of shocking. 

Point B

Also, I can vouch for at least 3 current developers (and even more if we included retired ones) that are well able to use shells. If you genuinely only know Lua and have never touched another programming language and system infrastructure before, I'm not sure one is even fitted for the developer rank. Yes, in enterprise-level companies you require developers who only know one specific area, and thus it is fine there. But as mentioned previously, FL is so far from enterprise, and developers literally need to be experienced in so many areas. I remember when FLs harddrive crashed and Conn (I think it was him) had to literally spent days trying everything to restore any data, and actually succeeded.

I'm not saying that there is a lack of shell knowledge. I'm saying that there lies a lot more behind the shell that you might not have enough knowledge of. Setting up and managing a linux server goes far beyond basic shell operations. Mistakes made in this area can cause huge implications (data leaks or failure). When you have people on the team who actually have the knowledge and experience (cause it's their daily job) you'd have to respect that, especially when it's of high importance to keep it secure.

We're in a small community full of volunteer developers. Mistakes can, and will be made. There will be people who are more experienced, and people who will be less experienced, but with working as a team, we can succeed it a much quicker and greater fashion than if there is a constant need for the best to be the only ones that have the capability to do something, especially when plagued with inactivity. 

I personally find it insulting to have been so blind sighted following a vulnerability in a year-old piece of code I wrote as a temporary fix, especially considering amateur blunders such as leaving indexing on, writing code with multiple XSS vulnerabilities, and so on. Mistakes will happen, we have to work as a team to fix them, and work as a team on the project as a whole. 

Point C

I wad involved with the data recovery process. Most of it went lost or deemed unusable. The actual data recovery was unsuccessful. Almost everything was restored from off-site  backups or was reprogrammed.

This is factually incorrect. Both gamemode database, and forums were recovered based on that data recovery effort. To put this into context for those who aren't aware: we lost around 2 months worth of data rather than 12 years worth - if this is not a success, I don't know what is.
The reprogramming of many features was a choice, rather than a necessity; though I don't think it was a bad choice in many cases. 

Point D

Everything has it's reasons, being fair or not. We still have a community to serve at the end of the day, and we all have the intentention to this as good as possible. In order to keep that going well, we all have our own expertises and roles within the team. A role we should stick to. Just because you're an admin, and you can code a little doesn't make you a programmer. But that doesn't mean you can't become one. The most beautiful thing about a community like this is the ability to contribute freely. Learn from each other, extend your horizon. But respect the knowledge one another has. Understand that some can have more knowledge about a certain subject, and it might be better to leave them to the more dangerious tasks.

I contribute with this belief. I want to create a safe environment where we can connect and collaborate. Respect each other, and learn from them. Where you are free to express your expertise and share your knowledge. That is the community I found 9 years ago, and that is the community I keep fighting for.

Point D funnels into my final point here. You cannot preach for such things without actually showing it yourself. As a team we worked extremely hard to recover from the data loss last year, and we have worked together to consistently improve the quality of development, however, with your step up, originally coming with a title of 'development co-ordinator', the development team have been constantly and needlessly blind sighted. 

It truly is unfortunate that it has to come to posting this on the public forum, but considering your unwillingness to tackle the issues in a conversation from March, I feel there's not much chance anything else will have any effect. There has been no respect shown from yourself when working behind our backs to remove access from developers. 
We need development team communication when working on workflow, when managing the infrastructure, and when working on projects. This won't work whilst there is such a divide in the team, that I personally believe has been created largely by yourself and your blind action.