Why can't new issues be created in the main repo?

[anohren]

I was just looking for a mention in e.g. the readme of the main repo about why issues can't be created for the time being (except by contributors). That would be helpful. Is the project migrating perhaps?

[ghost]

I wonder the same thing,cause I wanna create an feature request.

[strycore]

There are too many bad patches and invalid bug reports that come through if I let everything open. I have to take care of all of it and it negatively impacts the rest of the development really badly. Since I have to take care of those issues because no one else will, I prefer to have the code bug trackers closed. I was planning to reopen in 6 months but I like it this way, I feel way better now, less stressed. So I might not reopen... I've noticed that this is becoming more and more of a problem for a lot of open source projects (I've seen FreeCAD raise the same concerns).

Long story short: Having an open bugtracker drains me and if you want lutris to exist it has to remain this way. (Or, you know, I also welcome a project manager to step in and do that shit for me).

[anohren]

Thanks, that explains it. It sounds like you've been in a stressful situation.

This is just an observation from an arbitrary visitor to the repo who knows next to nothing about how the project is run: are you doing this alone? I get the impression from what you say that you think this is apparent, but I did not know anything about that.

If I skim through the readme I can't really get an idea of how many people are active in any particular role, but mostly that "developers" are referred to in plural, i.e. I don't really get any sense of the size of the team nor their respctive workload in relation to the current issue/PR pressure. Perhaps if the assymmetry was made more visible, something could be done about both the quality and quantity that you mention.

I often wonder how people deal with that kind of assymmetry, and even though I find the problem interesting I usually have to tell myself "well, if they haven't mentioned it in their reply/contact form/issue template it must not have gotten out of hand", and forget about it. Maybe there's some solution there.

Come to think of it, youtube-dl are very strict in this regard which I always found sensible.

[strycore]

That's true, I try to make it sound as much as possible as if Lutris is a team effort because I would like it to be. This is regardless of the amount of work I put into the project. I've never really wanted to drive this project alone and yet, this is kind of the state of things now. That doesn't mean that the project doesn't have people helping. Things are getting pretty good on the translation side with more and more translators from various countries stepping in. Also on the packaging side, things have been pretty good with Lutris now in Debian and Ubuntu (and pretty much every other major distro).

What I'm really concerned about is driving the project forward. There are a lot of things planned and the project needs to keep extra focus given that the area the project lacks the most in is development. It's not that I don't get any development help, but it's hard to keep patches I receive aligned with the project's goals. If let completely open, I start receiving all sorts of features that go in all sorts of direction. I receive stuff that I've never asked for and do not want to maintain myself. I don't believe it is my job to go boss people around and tell them what to code on. But it's not my job either to just absorb everything that is thrown at me and have to sort through it.

Now that the project is available in all distros, we have to be careful more than ever to ship stable releases. Nothing can be experimental anymore. Combined to that, the client still needs some very delicate rearchitecturing regarding the management of processes, which we need for Steam and other storefronts. There are also some major changes coming to the websites and how installers and issues are treated. Those are very large features, touching areas at the core of the project. Either I'm getting help for those things specifically, or I do those things alone. But every time I start a big feature, the bugtracker starts to go crazy. Some projects just don't have a problem with tickets pilling up, but I do. In recent months, the situation has become worse than ever for some reason. The feedback is becoming less useful, noisier. The patches I get are random and most need a lot of work or just don't fit in the project. I do realize how negatively this might have affected me over the years. I was expecting that limiting access to the bugtracker would have positive effects on my general well-being, but I didn't expect it would be that effective! I really think this was one of the better decisions I've done for the project and my only regret is that I didn't do it sooner.

[tangodev]

I was initially puzzled by this decision, but after reading this you have my full support. Your mental health is extremely important and I respect that. I want you to succeed and I want this project to succeed.

Thank you!

[anohren]

I felt put in a tough spot here since the issue turned out to be being distracted by Issues, and this is technically one of those... But you replied rather enthusiastically so I guess I'll compromise by asking just one of my follow-up questions:

Where do you visibly advertise in no uncertain terms that you're in need of developer volunteers? I can find some paragraphs telling people they're welcome to contribute, but none underlining that there is in fact a shortage, that that's a problem, and what the consequences are. Are you giving potential contributors enough information to make the decision? Are you telling them that they will be useful?

I had imagined that advertising on the lutris.net frontpage would be free, but the only advertising I can find there is for (presumably) non-affiliated games. Well, not the only, but the Contribute part doesn't convey any urgency or that the project will suffer.

[tangodev]

I second that @anohren . If help is needed, then maybe reach out. There are coders, hobbyists and pros, who have a stake here (they want to play games on Linux). But they have no idea about said issues. Maybe just ask explicitly?

[strycore]

There's a bit of a misunderstanding I think. The project wasn't really lacking in number of developers, quite the opposite actually. The issue is dealing with people sending contributions when most of those contributions aren't aligned with the current milestones, are often sloppy or sometimes even show a complete misunderstanding of the project. At this point it just becomes simpler to limit access to the repository, this seems a better option than having me yell at random people for the effort they put into their patches... While I do have some training in project management, I do not have the training required to deal with a bunch of random people each going in their own direction. I don't know why the regular process is so complicated to others. I look at the next milestone to be released and treat each issue one after the other and I continue until everything is closed. Note that I've reviewed something like 5 patches since I've closed the repository and none of them were worth merging. At this point, if there is a setting to only re-open the issue tracker without re-opening the pull requests, I will choose that option.

[anohren]

Oh I see, you said lacking in "development" and I assumed "developers". You're right, they're not the same thing. Sorry about that.

Too much time is taken from (a sufficient number of) developers whose contributions align with the project by developers whose contributions don't, hence the lack of development but not developers. I hope I got it now.

I don't know why the regular process is so complicated to others

That is an interesting problem...

Anyway, it sounds like you have found an effective solution that you're happy with. Good enough is good. I hope conditions continue to improve.

Thanks for clarifying!

[smichel17]

I think addressing issue overload is supposed to be the point of the new "Discussions" feature. Unfortunately, I don't think there is a setting for restricting issues/PRs while keeping discussions open.

[strycore]

I have opened the Discussions part of the repository in preparation of reopening the bug tracker. There is no need for other features on Github, this is going according to plan and the bug tracker will re-open when planned if not before. I have 10 years of technical debt to pay, this is not something I can do while constantly being interrupted, but also it's possible to get rid of it by just focusing on it for a while. Once the project isn't in so much technical debt, I can take a more mentoring approach to assist junior devs who need help figuring out the structure of the project.