<Comment deleted by user>
why are you the authority on which code gets added and which doesn't. and why do you know better than the coders who built the features?
Thanks for sharing this viewpoint. This clear a lot of doubts about "new features policies" I had, not only of Lichess but in general.
Someday I was going to ask you if a second free and open source engine (like Leela Chess Zero) could be added to have a second opinion beyond Stockfish, but I'd guess I already have my answer. The pain of maintaining it would be much greater than the little extra benefit it could provide.
Thanks again, cheers!
Someday I was going to ask you if a second free and open source engine (like Leela Chess Zero) could be added to have a second opinion beyond Stockfish, but I'd guess I already have my answer. The pain of maintaining it would be much greater than the little extra benefit it could provide.
Thanks again, cheers!
@pawngrid said in #22:
> why are you the authority on which code gets added and which doesn't. and why do you know better than the coders who built the features?
He is the founder of Lichess and the one who actively maintains it.
Perhaps a little more research next time?
> why are you the authority on which code gets added and which doesn't. and why do you know better than the coders who built the features?
He is the founder of Lichess and the one who actively maintains it.
Perhaps a little more research next time?
<Comment deleted by user>
@RedSword69 said in #17:
> I also feel that the decision may depends on the code/modification needed to accept the resolution of an issue; but in some cases it seems it could have been marked as "Won't do/fix" before.
I think you're right, this is also the point of the article. It depends on the important of the issue and the complexity of the "fix". We have to weight pros and cons here.
The best would be, fix the issues and clean/reduce the code at the same time but that really hard. If We fixed the issue, but add a more code and additional performance penalty, we really have to consider.
> I also feel that the decision may depends on the code/modification needed to accept the resolution of an issue; but in some cases it seems it could have been marked as "Won't do/fix" before.
I think you're right, this is also the point of the article. It depends on the important of the issue and the complexity of the "fix". We have to weight pros and cons here.
The best would be, fix the issues and clean/reduce the code at the same time but that really hard. If We fixed the issue, but add a more code and additional performance penalty, we really have to consider.
i want a new variant
I understand the point of the article very well. As a software developper I have to say that the question of future maintainance is highly underrated by most people who do not have to do it theirselves (that is: customers and bosses).
Still. sometimes I have the impression as if some feature requests that appear in the forums seem sensible and doable - but we never read any answer from developper's end. Sometimes after a couple of months or even years it is suddenly there, sometimes not. For example, there were at least ten "feature request" threads for rapid time control (something between classical and blitz) before it was suddenly there.
I understand if the answer on requests is a blunt "no", but sometimes an answer like "we see it is desirable, but we can't do it" or "we plan to do it, but not priority #1" would be nice. That would also help answering superfluous repetitive new threads.
Still. sometimes I have the impression as if some feature requests that appear in the forums seem sensible and doable - but we never read any answer from developper's end. Sometimes after a couple of months or even years it is suddenly there, sometimes not. For example, there were at least ten "feature request" threads for rapid time control (something between classical and blitz) before it was suddenly there.
I understand if the answer on requests is a blunt "no", but sometimes an answer like "we see it is desirable, but we can't do it" or "we plan to do it, but not priority #1" would be nice. That would also help answering superfluous repetitive new threads.
I like this site because it makes chess playing very easy,
plus you can learn a lot here via lichess TV.
plus you can learn a lot here via lichess TV.
@Diceroller_is_Fire, by the way what is the variant??