We currently lack some stuff, we can do better. For me, this became obvious in the process of the GSoC application and by honestly comparing ourselves with other oss projects.

Our documentation is not as clear and friendly as we think
- in fact, it is often missing "the obvious stuff"
Our development team is currently on highly fragile feeds
- just very few able to do sth when none else is doing sth
- of course this is also a problem from poor documentation of new systems
- but also a motivational problem to "strive forward to sth"
  - even when others are currently not helping to assemble the thing together
Our communication should be more transparent
- also a part of documentation maybe, but also issue/project management
- also error-communication like "i do not like this", "i dislike that", "i currently can't find a way to"

The good thing is that improving them individually will impact all of them together.

Ideas for the different parts? Besides from "improving the docs" :D A Doc-improving party? Bringing back meetings to present individual milestones, working areas, presenting new features to the others?

As an almost outsider, I know why it is so hard to get started contributing with this project :)

There are multiple interest groups that take care about larger parts of the system. As I see it, as of now there is:

core engine (@a-teammate )
website (@IAmNotHanni @Fohlen )
flex (@aschaeffer @Fohlen )
game content like textures ( @koppiman )
documentation and licensing (@Croydon )
UI & CEF (@aschaeffer )
build/CI (@Croydon @aschaeffer @a-teammate )
Marketing (@Croydon )

Please correct me if I forgot someone. As an outsider, I have no clue where @movabo or @super-tux really contributes to. But core engine would be a good guess. While each I personally think, it is important to have these interest groups, it is hard to see how they depend on each other and how they can work together to deliver one single product - the game.

I think it is important to know who to turn to, for these interest groups.

I personally would love to be involved with the ingame UI and website/marketing. I also contributed to ui-prototype a while ago, but I have no clue where to go from there. What the requirements are, where I get data from (flex?).

While it is a good thing that these groups can grow independently, there should be a product owner that guides new interested people to where help is really needed and how to contribute. New goals and interest groups can always be created, however with only the issues and a bunch of labels, it is hard to tell where contribution is most needed for the desired interest group.

I think a collection of issues is just the start. From just the issues, it is hard to tell in which state the project currently is. These individual groups need to have goals defined that can be worked on. (Sprints if you will, if you are coming from a professional development environment)

So the first start, we should document these interest groups and how you can start out to contribute for the individual project goals.

I do not think that more tools like Trello will solve this, but having a good understanding where the possibilities are to move the project forward is valuable for everyone.

We have Recruiting in our wiki, which explains the various topics to get involved with, but not how to get involved with, other than reaching out to us. This has to be changed :) You should know from reading the wiki how to get involved.

We have Contribute code but it only explains in what format we want to code, not in which places code can be added.

I really like the idea of clearly defining Working Groups. I agree that it should be always tracked for each working group what its plans are and what is currently doable. And we need to define for each of them in how far they are connected to other working groups to group up the complete package.

For the recruiting part I imagine the hardest difficulties newcomers need to overcome besides finding out what is doable is the way we expect things to be solved. I.e. we always look for the elegant solution which does not only solve one, but many issues. However we do not document that anywhere and neither do we document how to find these solutions. We only say how the code should look like, not the solution.

Also, we should define and document a "best practice" when to use issues, chat (Telegram/Riot), wiki or hackMD(piratenpad, etc). There are so many resources to dig into and it is confusing for newcomers to decide which tool to consult for which information. I'm preparing a wiki page for this and also the working groups. Since you know these groups the best, it would be nice to extend these pages then.

Also, we should define and document a "best practice" when to use issues, chat (Telegram/Riot), wiki or hackMD(piratenpad, etc).

what about making that a decision tree?

For that page you'll need

What defines a working group? Interests? Skills? Both?
How is the lifetime of a working group defined
- i.e. when is it important to work in a particular area?

@Croydon

Next to missing information, we also have the problem of duplicate and outdated information.

This is very true, so we this information should be really easy to get. short, precise a good guidance.

I agree that we should strip down the readme. And of course we need to simplify the setup, but well, that is work. and that is why we have an issue about "project management". To clearify why this work is not done. This issue is not about getting new persons mainly. it is about how to organize ourselves. If we succeed in that, other people can jump in easier, too.

You are right, that we need to clearify the current state and the very next steps in a transparent way is the main point this issue is probably about! (plus together why the very next steps are the very next steps: so we need to clearify the overall vision a bit, too. and also the type of solutions we choose)

Our documentation is not as clear and friendly as we think in fact, it is often missing "the obvious stuff"

Yes. For example, how can I start the game? The reason why a random new person is here. Or, at the end of the day, we all.

Or can I even run the game? We need to get finally stable in basic building and basic running of the game (aka. a lot can still be broken, but you can do something). Running Inexor doesn't only needs to be possible but damn easy. This is was drives people away. This is what demotivates people the most.

It's very hard to get it running for core members. When you don't even know yet if you like the project at all then you won't invest much time in debugging.

Ideas for the different parts? Besides from "improving the docs" :D

Next to missing information, we also have the problem of duplicate and outdated information. Please, please stop duplicating information. I'm sure we have at least 5 places with the same basic information how to contribute to our project. This doesn't help, it's contra productive. And it won't get new contributors to us. An easy start into the application (aka. building and running) can hook people to the project because they like what they are seeing. No documentation on this planet can do this.

Completely new people also don't care what we have planned. They care about the present state.

(Our readme has some weird roadmap-ish thing, which I always considered missplaced, we also have milestones for release planing, we have now a flawed roadmap issue (definition of done? same function as milestones and the respective detail/implementation issue itself) and we have laid down in who-knows-how-many wiki pages what our vision overall is. => Information duplicated all over the place + the readme is the first thing new people see, they don't care about our future plan.)

Working groups. I don't like the idea. It's introducing hierarchy which we tried to avoid so far. And it's adding bureaucracy time in which nobody moves the project further. Also this idea isn't endless scalable nor very open to outsiders.

@MartinMuzatko Honest question, why do you need to know who is doing what? In my opinion, when you want to contribute you should only need to know HOW and WHERE. It should be never required to know the internals of an existing team.

Have a look at big repositories, apart from the core team nobody knows anyone. This leads me to a more general point: I have sometimes the feeling like we treating this still as a small, closed down project. We should stop doing that.

Nobody needs to know that I'm making currently the biggest part of the CI. What is the place for suggestions? -> Issues. Anybody who has an opinion on something can comment. People who are actively involved in the part you are talking about, will comment for sure. If you open an issue about CI I will almost certainly comment on it. How to contribute? -> Open a pull request. People who feel responsible for the project part you touched will get in touch with you for sure. (Of course this involves more like coding standards ect. but to be honest GitHub is placing an obvious message above pull requests, so there is no discovery-problem here).

It's nice if we all have some form of personal contact as well and actually know each other, but this CAN'T be a requirement for a truely open source project as this is NOT scalable and doable at all for big projects. And it is not required. Have a look at huge open source projects.

So the answer to

I think it is important to know who to turn to, for these interest groups.

is: GitHub issues.

Another thing which I'm missing is overall consistency. Being it with information (see my first two points) or how decisions are being made.

Sometimes issues are literally open for two years without a decision, others were sometimes only open for hours (or two days or another short time) before some decision was made by someone, preventing more people from commenting.

The same was true for pull requests in the past, but since we do require approvals in Core, Flex and media essentials this got much better here. I don't like at all to add bureaucracy to issues so I guess I don't want to add a completely formal process how decisions are made, but they should be long enough open to give everyone a fair chance to answer and there HAS TO(!) be enough input. Obviously, what this means varies strongly. A huge decision about the creative direction should take a long time, because it has such huge and potential irreversible consequences (from a project view point), but a trivial bug fixing issue can be done in relatively short amount of time (if the fix implementation is non-controversial). This requires a good gut feeling and constant self-reflections about the gained experience from previous discussion/decision makings/implementations cycles.

And when decisions are made: And they should be made nowhere, except on GitHub issues, then they need to be replicable and documented. A complete stranger should still understand why and what decisions were made five years later.

It was way too often that even I am didn't know about decisions for a (relative) long time and I literally read everything (all GitHub, all chat messages, all emails, all social media stuff.....) all the time from the beginning.

I also noticed several times, that based on the feedback from few or even a single person, who discovered our project new, people started to instantly change readmes, wikis or other stuff. That would be okay, if we have actually learned something new from the feedback and would continue doing things in this specific new way, but often it was like a one-time-thing. For me, that looks impulsive. More consistency, please?

Just one small-ish example: Remember when we wanted to have a wiki template because people were thinking our wiki is a mess? Pretty much every new wiki page doesn't use it anymore. Is this good or bad? Who knows. But it's definitely inconsistent.

I'm sure we would actually drive faster when we take more time for considerations.

This is a marathon, not a sprint.

Completely new people also don't care what we have planned. They care about the present state.

I disagree. When I found out that there is a fork of Sauerbraten that finally focuses on modernizing the game to make it as modable and adaptable as possible, I was instantly hooked and was really hyped about this project and especially about its future plans and how I can contribute to that.

I think it is important to avoid duplication as you say, and have only one solid place where we present our current state and future vision. The different platforms are however used or abused to duplicate this content. The website should be the first go-to platform to gather that kind of information as a visitor/newcomer, but for internal organization and planning, this is not really a good place, which is why this is spread across many sections. This is also why I asked for a "best practice" of where to discuss/collect/present information. As you see yourself, it is not always that safe to assume where to put something, so we have to decide how to establish a sane convention there that is also documented.

Working groups. I don't like the idea. It's introducing hierarchy which we tried to avoid so far. And it's adding bureaucracy time in which nobody moves the project further. Also this idea isn't endless scalable nor very open to outsiders.

First of all, I'm sorry that this looks like I wanted to introduce bureaucracy and hierarchy. I just talk about my personal experience with the project and about getting involved.

@MartinMuzatko Honest question, why do you need to know who is doing what? In my opinion, when you want to contribute you should only need to know HOW and WHERE. It should be never required to know the internals of an existing team.

The project feels locked down in many parts. I can propose a ui-prototype, but I have no feeling of progress when nobody tells me how or if this prototype will be used, or if it is just a plugin as part of Inexor Flex. Especially in this field of area, it is very uncertain how it will turn out in the end.

I am not sure how my work will be used for Inexor. This may be different for flex and the core engine, but in my experience regarding the website and the UI, it has always been quite difficult - even with considerable effort from my side - to make a dent in the development of Inexor. Since there is nobody here to guide me or tell me further feedback how to progress with that and how to incorporate it with inexor flex, I feel left alone with that work.

It's nice if we all have some form of personal contact as well and actually know each other, but this CAN'T be a requirement for a truely open source project as this is NOT scalable and doable at all for big projects. And it is not required. Have a look at huge open source projects.

When you compare us to bigger projects, there are distinct issues for distinct problems. Little additions. Or if it doesn't fit into the core system - it will become a plugin. At Inexor, we still have to carve out the bigger main ecosystem. There is no real plugin system where you can just plug your stuff into and make it work, so you don't need to have others be accountable for your content or that it gets introduced. AFAIK flex is starting to take shape and may solve this in the future. But especially this kind of issue means, that there IS an order of operations, an order of which thing to solve first. I can work on UI all the way I want, but as long as there is no way to make it part of the game, it will just stay as a proof of concept.

When you create something like a proposal for a bigger part of the system (because a UI requires a lot of initial work before something can be seen - like a build setup, design system, integration with flex and so on) and get no feedback, it is very discouraging to continue. At this point, someone just has to take the responsibility for a part of the system and guide further contribution and collaboration. As you have seen with the ui-prototype repo, there are now 4 or 5 proposals but nobody knows how to push them further. Does someone have to decide which prototype can be used? Is it all a plugin and are they optional? While we collect ideas and proof of concepts, we didn't decide at one point, which of these to push further, which is why we still have - to this point - no ingame UI.

Otherwise, I can just agree with the other points you mentioned, especially regarding the decision making. However, as I said - someone has to make the decision in the end, and be it the one approving the pull request. If in the case like outlined above with the UI prototype stuff, someone has to take it from there on and start deciding which UI to use and how to incorporate it with flex/the rest of the game. This part was also very unfortunate and misguided in the previous years. Cases like these require me to have direct contact with the team that authors the core codebase. Otherwise I wouldn't know how to go from there.

I also noticed several times, that based on the feedback from few or even a single person, who discovered our project new, people started to instantly change readmes, wikis or other stuff. That would be okay, if we have actually learned something new from the feedback and would continue doing things in this specific new way, but often it was like a one-time-thing. For me, that looks impulsive. More consistency, please?

Well, why not act on feedback? The actual problem is that just small parts get changed when the overall introduction needs a revamp. Thats why we have this issue as well.

Bureaucracy

Working groups. I don't like the idea. It's introducing hierarchy which we tried to avoid so far. And it's adding bureaucracy time in which nobody moves the project further. Also this idea isn't endless scalable nor very open to outsiders.

If we say we are non-hierarchical, but actually do have hidden hierarchies we are not more open, but less transparent. The key is to be transparent and open: be transparent about how decisions are made, but at the same time make it open to new people to quickly make an impact in these decisions.

I am speaking about informational hierarchies here and hierarchies which appear just because someone is more involved in a particular topic and gives the main direction. How to overcome that as a new one? There is currently no structure which resolves such stuff. The current idea is, that people get more and more involved in a particular aspect, that they become experts there and their knowledge and skills make their opinion matter more in that area. But there is just no documentation about what areas exist, how many experts already work in that area and how to be one of them.

Issues have limited information. You can not document every and any decision you make as a developer (why did you name it "isgreyscale" and not "iscolorized"?).

Issue Management

If we could split our issues somehow to be really really tiny, people can actually help somewhere just in the middle of something.

But: how do you still make people feel responsible for the bigger issue? There needs to be a flexible way to document what the overall goal of the issue is, additionally to the minimal sized issues which could allow quick progress (and multiple concurrent working persons).

Working areas

Yes, I agree that writing people down somewhere in the wiki won't cut it, but that's not the idea. The idea is to guide and organize people based on their interests. It is not about a wiki page called "who does what", it is about an organization structure which is modular in such a way, that people immediately know where they want to contribute.

Imagine examplewise a wiki page about the (possible) different stages of development and the working areas when which areas are unblocked under which circumstances. Then for the different working areas clearly listed, what current ideas are, what currently doable mini-issues are and what the result will probably look like in the end.

TL:DR:

smaller issues, please. (but how to still make the bigger issue visible?)
informational hierarchies always exist, but it should be clear how to overcome them
- more documentation probably won't solve this, but relevant documentation: a history of decisions to this point + the vision(s)

@MartinMuzatko Yes, the structure of flex probably needs some tutorials for some stuff. But imo it is the same issue as in the other areas: normal issues just don't cut it to document the organizational structure, the vision, the already processed steps and the currently doable stuff.

I think the best is currently to ask the experts of an area directly. and probably the best is to do that by arranging a mumble-meetup. That makes people depend on a tutor, while I think that is not really a scalable approach.

So, hey palls, sorry for being late to the party, I've been a bit busy with life currently. Here's my 2 cents to the topic. Excuse me if I only gradually comment on things because the conversation has grown quiet large.

Documentation and why it's so hard to on-board Inexor

I do think our documentation is quiet good and detailed. There's some quirks every now and than, but overall, compared to the size and manpower we have, the docs are amazing! The problem I see is that we lack a "goal", a vision of what we will want to see when the game "finishes". This lack of a common goal also makes it hard to lead somebody to Inexor. How can you understand something we do not even internally have a vision of?

So, to tackle this specific issue, I will sum up what's been said here as a solution, and add a few of my own ideas

use roadmaps. They're there for a damn reason! They give you an idea of what you want, and the precise thing can grow as you go. No roadmap means no idea of what needs to be done next.
smaller issues (how to increment something with 5000 lines of code?)
getting it set up: it's currently our biggest burden, and we will need to rapidly improve in this to attract new contributors. I think we did make quiet good progress on this issue, but it's far from being solved.

Working groups and responsibility

So, firstly, I would like to comment on responsibility and "personal" contact.

It's nice if we all have some form of personal contact as well and actually know each other, but this CAN'T be a requirement for a truely open source project as this is NOT scalable and doable at all for big projects. And it is not required. Have a look at huge open source projects.

If you look at old, big, "massive" open source projects, you will notice in all of them:

they are truly interconnected and almost every contributor knows, or has heard of every other
somebody is in charge of maintaining things, PERSONALLY
this is just a social requirement. OSS is a community. Take the community part from it, and it won't work...

I do think working groups are useful for tackling specific problems. e.g we plan a major feature, so we form a working group to tackle this problem. Other than that, I would suggest sticking to maintainer responsibility. These roles could switch every half a year or so, so somebody doesn't get a lonely maniac with all the information and get's crucially important for the future of the project!

Hierarchy and bureaucracy

Hierarchy sucks. Seriously. And if we look at our internal structure, we have a "absolute minimal hierarchy" needed to run things that require e.g money, but for everything else we have a very lovingly working merocracy. I do see myself and the @inexorgame/founders as competent contact persons who have been around for a long time, but that's it basically. No one of us is power mad, no one of us likes hierarchy, we want to get things done.

About bureaucracy: there has been quiet a lot of talk now how to dense information and add stricter guidelines. I party agree with this in the terms of:

we need a way to guide ticket development. Who to talk to? When is something considered "done"? How long should a ticket take? How can we speed up things? Seeing somebody making a PR with seemingly no progress is just frustrating, for him as well as for us.
we should also add a better way to document structural decisions. Either be consistent with hackmd or use GitHub issues.

That's it basically. If we get those right, we will be fine for the next 5 years, probably. Don't overdo it. Don't guideline people and force them to use GitHub issues all the time when all they want is just hack together some idea. Too much is a burden.

Final resumee

So, here is my proposed solution how we can go on with Inexor structurally

add ROADMAPS for our projects. This worked really nice for 0.9 release and we should stick with it
add a "definition of done" and a guideline for contributions that's more transparent than our current one
add a template for decision process. How and when was something decided? Where? Should we host a monthly or bi-monthly meeting in some kind of form to talk about current issues?
add a system for maintainers. I propose: we "elect" a person for a certain period of time. If he accepts, he/she will be in final charge of pull requests and releases. This system should also force people to cycle between projects. (maybe half a year is good, dunno). For really big projects such as flex and core this could also be a board of 2 members.
form "working groups" for specific tasks derived from the roadmap. These should not take longer than a maxima of 2 release periods. Keep things as atomic as possible so they don't get stuck.

With the proposed changes I do think we could get Inexor development a lot more straight. My last words are, can we come to a conclusion here, maybe add a voting so we can get this issue clarified? Maybe @Croydon can organise it, because he had some clear talent for it in the last few votings?

TODO in this issue:

[ ] List all the good ideas
[ ] Create a specific issue for each of them
[ ] Make this issue a meta-issue for the specific issues

Probably we should also define a github label "feat:organization"

An example of (imo) a good overview over a project status (small issues, clearly sorted) https://trello.com/b/lp1XjYaz/ue-viewer

I think this issue can be closed after this Hackathon.

Currently I assume this to be "fixed", also in the reflection of the number of mumble meetings we had since.

Please forgive me to use this issue for my following words. However, I believe that it is much more appropriate than posting the following simply in Riot/Telegram/IRC or creating a completely new issue just for this comment. Please also forgive me, that this will likely be an incredibly long comment and that I'm repeating many aspects within itself. However, I want to make some points as clear as I can. But even then, I have much more thoughts in my head as I could possibly write down.

Reasoning

One of the aspects I respect deeply about Inexor is that it tries to be an open project, where people can jump in at any time and can help to form the shape of the project. Like in any democratically or democracy-ish system everyone in it needs to accept that there will always be many decisions which are contrary to the own personal opinion.

I'm also respecting and accepting all decisions which are made in such a democracy-ish way within the Inexor project. At the same time, I also have to face the reality of this project and I'm noticing that it took a huge sidestep compared to, what I believe, was the original vision of Inexor.

Inexor was born out of the Sauerbraten community. Sauerbraten has no active development for many, many years now and the community and the game are slowly dying. I, and I believe many others, have seen Inexor as a last attempt to turn things around and keeping the community as well as the Sauerbraten gameplay and the Sauerbraten look&feel alive. Inexor, the Sauerbraten fork, should stay Sauer, but can become better in every other aspect. Most importantly, Inexor, the Sauerbraten fork, should stay Sauer, and stay alive.

I'm facing the reality of Inexor and I'm accepting that it took a huge sidestep to this original vision due to many small and many huge democracy-ish decisions the Inexor project did collectively in the last years. This project is not any longer the project I decided to join and decided to spend so much time and energy on it.

Consequences

I want to act in a transparency and reliable way within every project I am in. I'm currently one of the administrators of Inexor, so I want to be able to stand up honestly and can truthfully support and defend all decisions Inexor made, including all of the decisions I voted against myself, because I have a very strong sense of teamwork.

I can't wholeheartedly do that anymore as the reality of Inexor is such a huge sidestep to my personal vision, and what I believe the original vision of this project was.

As a consequence, I will step down as an administrator of Inexor herby immediately. I'm also bringing all major work I'm doing for Inexor to an end.

I will

transfer the Facebook account ownership to @aschaeffer and removing myself from it
remove my IFTTT bridge from Twitter to Facebook, someone else needs to re-create such a bridge, if you want to continue to be able to only post messages ones for all social media platforms
transfer the Bintray organization ownership to @a-teammate
add me to the "Former Members" team on GitHub
downgrading my GitHub permissions to a regular organizational member
downgrading my Riot permissions to a moderator
downgrading my Telegram permissions to a regular member
remove me from the Inexor Twitter account as an administrator
change all accounts' email addresses to info@inexor.org
leave the encrypted Inexor Core team group in a few days (this group was used mostly to exchange credentials)

Beyond that, all remaining administrators should have all credentials and permissions to all accounts I have ever created or maintained in the name of Inexor.

However, since there is such a huge amount of accounts on so many platforms I'm not entirely sure I have considered all accounts. If you should notice now or in the future that you are still missing credentials or permission please don't hesitate to write me at any time on the common platforms. I won't vanish 😊

My decision to leave isn't a sudden one and so I took care in the past several months, that if I'm leaving, the things I have worked on the most are in a sane, maintainable state where others can take over more easily. I believe I have done this now. The last major thing I would like to do within the boundaries of Inexor is to get the Conan recipe for gRPC mature and then to push it to upstream support, or if they should have a change of mind, pushing it over to Bincrafters.

As soon as my remaining work is completely done, I will

remove me from all GitHub organizational teams, except "Former Members"
remove @CroydonBot from the GitHub organization
remove me from our Bintray organization
remove me as a moderator from Riot. At this point, someone else needs to periodically check out the bridging IRC <-> Riot <-> Telegram, or it might just die at some point

Conclusion

Thank you, all past and current members of Inexor, for all the time we spend together, both virtual online and physical at Hackathons. I learned a lot on this journey and we really got some great work done.

We did work now 4-ish long years together on Inexor. In some way, this feels even much longer for me as I could add easily all the previous years on top of it, which I did spend on projects related to the Cube engine ecosystem.

All of my former Cube-related projects did fit into my Inexor vision, so all of these projects where kinda combined and consumed by my efforts I put into Inexor. Due to this, it felt more like a formal change of labels and names when Inexor started as I have worked already on many of the same concepts and ideas before Inexor was born.

To just name a few:

LibreCube, where I worked previously on getting the Sauerbraten content to be fully open sourced. I did work on this with Meow - greetings to him, wherever he might be now. I'm actually considering this project successful, due to the License Policy Inexor adopted and due to the fact that media-essential is now finally fully open source. (Even though a lot of the default icons, sounds and models needs still replacement, which are now located in media-additional). Please don't go off-track with the 100% open source effort ❤
zombie-menu and all zombie-related co-op editing efforts, which tried to combat the fact that Sauerbraten's UI is terrible and terribly incomplete and co-op editing is lacking so many important management tools. Zombie-menu was founded and mainly maintained by Meow, but many people, including me, contributed. Zombie eventually died down due to, I believe, personal reasons of Meow
noobmanager, which was my personal prototype to dynamically download, install, enable, disable and delete custom content with a few clicks
Nooby's Script Library, which was my Cubescript-only framework-ish beginner-friendly effort to make it easy to install, enable, disable and configure CubeScripts via in-game UI
Nooby's Paradise, which was my public custom race server, long before race mods got popular (again)
all of my race maps and puzzle maps I built either alone or with Waterrater together ❤
and just who-knows-how-many-stuff

I want to be absolutely clear about the fact, that my decision to move on is neither lighthearted nor sudden, but developed in, I guess, the last ~18 months. It took such a long time because I deeply care about the Cube ecosystem in general and the original vision of Inexor. I didn't mention considering leaving before, because I tried to win majorities for my point of views with rational, factual arguments, instead of a potential dramatically and emotionally -something-.

If you are searching for concrete concerns of mine, then you can also go back to many things I have said and wrote in the last ~2 years. I won't repeat them here, as such details are beyond the point of this post.

I have spent so much time working within the Cube ecosystem, that I'm not even sure anymore when I started. It is at least 8 years. So the best way I can describe it is as 8+ years.

When Inexor started, I and many others did understand this as the potentially last chance to keep the Sauerbraten community, the Sauerbraten gameplay, and the Sauerbraten look&feel alive. Now 4-ish years later I'm still seeing Inexor as this last chance. Red Eclipse is very alive and this won't change any time soon, but even though it is sharing the same technological base, Red Eclipse is simply not Sauerbraten-ish and I'm personally not that much interested in playing it, even though I believe it is a very decent game.

To summarize all of this, it effectively means for me personally, that I'm not only ending my personal working relationship with Inexor, but more-or-less my complete 8+ years working-chapter within the entire Cube ecosystem.

I'm still very passionate about the Cube community, the Sauerbraten gameplay and the Sauerbraten feeling and the original Inexor vision.

So the only thing left to say is: Please prove me wrong in all my points of concern. Keep kicking ass. Keep the Cube community alive. Keep the Sauerbraten gameplay alive. Keep the Sauerbraten look&feel alive. Make your version of the Inexor vision succeeding. I want to see you succeed. Best of luck. See you in-game ❤

Cheers!

Now, and forever, ― Nooby

now-and-forever-nooby

inexorgame-obsolete / meta

General Project Management Issues #4