Future of this project

[laktak]

Hi @gokcehan!

I really like lf, it's a tool I use everyday and I'm thankful for all the work you put into it. That said, there a still a few things that some of us would like to see merged into the project.

The current situation is a bit unclear. Can you let us know your thoughts about the direction you'd like this to take? Like can we help you with some tasks, would you prefer if we managed the PRs in a separate fork ..?

Also pinging @p-ouellette and @ilyagr as they are most active in the PRs atm.

[gokcehan]

Hello @laktak and thanks for bringing this up. I am quite busy these days so I don't have spare time to spend on lf development. Unfortunately, I don't see this changing any time soon. I think it has been almost a month since I was last able to take a look at PRs. Not only that but I'm also kind of frustrated with the direction lf development is heading in general. I have completely abondoned issues as they are mostly filled with configuration problems. Every time I see an icon configuration issue I feel like we should have never introduced icons in the first place. It might be difficult to imagine but lf was actually started as a minimalist tool. Nowadays it has come to my attention that even some of our early contributors abondoned lf due to feature bloat. It is also unfortunate that when someone moves away from lf they don't take away the features they introduced. This is why I'm hesitant to add new features nowadays.

I have now looked at the PRs you worked on and they mostly seem to introduce new features. On-select feature in #864 might be useful so maybe I can take a look at it at some point. I'm not sure about user defined options in #865. I'm generally against adding features making use of raw terminal escape codes as in the terminal focus event feature in #861. Selection mode in #849 has been quite fundamental to lf so far so I fear it might double our reported issues somehow. Of course all of these PRs deserve a separate discussion properly.

I'm aware that everyone has different expectations from a file manager. I usually feel uncomfortable being currently the only decision maker in the project. So I should ask our contributors a similar question. Is there anything I can help you to have lf developed in a direction you want? In #840 I suggested creating a wiki page or a section in readme to list our active forks for more visibility which is mostly a band-aid solution to this. In the past, there was an attempt to create an active fork with extra features not included in this repo with a similar relation between i3 and i3-gaps. For me the important thing is to come up with a development philosophy to decide which features should be included. For example, if you start an active fork, do you plan to include every patch? If not, then what will be the difference between this repo and the new fork? Creating an umbrella lf project might also be useful though I'm not quite sure how they work and I guess decision making might still remain as an issue.

This discussion is quite important and valueable to me so I can move this to issues and pin it for more visibility if that helps.

[laktak]

While I agree with you to a certain extent, making a computer do exactly what you want is one of the most powerful things. We are already very limited in most systems so IMO it's even more important to enable this for power tools. Having a basic vision for the project is great but in the end I don't care if it is polished or if the configuration has its quirks as long as it does its job and does it well.

There are VIM purists who only use it with its defaults but VIM also allows you to configure the heck out of it. I think the VIM way of doing it proves that this works very well as it enables everyone to adopt it to their preferred way of working.

I get that you don't want to maintain features you don't care about. But if you open the project up to more people there may be someone that does. No promises on the icons though ;)

[p-ouellette]

I appreciate lf's (relative) minimalism and hope that new features won't get merged without careful consideration.
Of course, everyone has different ideas about which set of features is the most important, so it's a difficult balance.

I think for new features we should consider:

• Can the same thing already be achieved with configuration or a script?
• Is it a use case we actually want to support or is it out of scope?
• Is it worth the added complexity?

[ilyagr]

I'm a bit late to this, but I'd be happy to help out (with closing some issues, especially), though I could easily disappear for a few weeks or months; my free time is a bit erratic.

@gokcehan , if you get the energy for it, I'd encourage you to more aggressively close the PRs you don't think should go into lf and issues you don't think are actionable. lf currently does feel like a program that follows a consistent vision, which is a reason I like it (even if the decisions are sometimes different than I would make myself). It does not feel bloated to me. @p-ouellette 's criteria also seem reasonable to me.

I see nothing wrong with a wiki page with a list of patches to lf, especially ones that you decide shouldn't go into the main version, but I also think that's a band-aid. I think it is valuable to have an official version which will eventually have a release and be included in distributions.

Finally, it's important to remember that you don't owe anybody anything. If you need a longer break from lf, take it, whether it takes another month, year, or the rest of time.

Thanks for making lf, and all the best!

[lahwaacz]

I second this. I could also help with closing and categorizing/labeling issues and PRs. There are many "support" issues that could be converted to discussions.

[laktak]

@ilyagr if you get the energy for it, I'd encourage you to more aggressively close the PRs you don't think should go into lf

@gokcehan I usually feel uncomfortable being currently the only decision maker in the project.

Well, unless you open the project to more people you are going to be the only decision maker. It's your project and you can do or don't what you like. Totally OK. Closing PRs you don't feel good about would be nice though.

[gokcehan]

Thank you all for discussion. As I understand, you want me to be more responsive to PRs which is quite reasonable. I have went over the PRs and merged most of them or dropped a comment about the reason for rejection. I'll merge some others in the upcoming days if you update them to resolve conflicts. I will also take a look at the documentation situation with Go 1.19 in detail.

I tried to be more open to features that I'm not interested in myself. In return, I ask you to follow issues in the days following your included patches to see if anything is broken for other users. As I don't have much time to throughly inspect patches I have only taken a brief look at patches for familiar contributors (e.g. people in this discussion). When you have time, it would be nice for you to inspect the patches of others so we can establish a control mechanicsm (which by the way is already happening).

Will this be an end to my periodical burnouts? Probably not. I might still disappear for a month or two in the future. Feel free to create a separate fork if you feel like it. You can also ping me if there is anything I can do to help you in this regard.