Php-cs-fixer: Unlock and reopen #454

[ghost]

454 has been closed and locked, despite the fact that it is still unfixed.

This is a bug-tracker anti-pattern on multiple fronts:

• It forces fragmentation of discussion, requiring people interested in the issue to read across multiple threads.
• It actively hinders finding such threads, because - at least on GitHub - when an issue is locked, subsequent links to that issue from other issues no longer produce backlinks. This means that someone who reads #454 will not find any links there to any subsequently-created follow-up threads, and will therefore not know if such threads exist. (If they are really persistent, they would be able to search the bug-tracker, but this is a never an entirely reliable process and is a completely avoidable inconvenience for you to impose on your users.)

Therefore, please unlock and re-open #454. Thanks.

[keradus]

https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/454#issuecomment-395723915

[ghost]

@keradus wrote:

#454 (comment)

That comment does not resolve the problems that I reported above.

[SpacePossum]

@sampablokuper Please write an up-to-date short description of what you would like to see changed. We simply don't have the resources to go through multiple older issues to evaluate where these are still relevant and if the comments on those issues are current as well.
We've more than enough _open_ current PR's and issues to consume the free time people can spent on this project.
You are free to disagree about how we run things here, but it is just a reality; if you keep posting meta tickets with a lot links over a multiple old tickers reporting what has _not_ be done, we'll never get to something you would like _to_ be done.

[ghost]

@SpacePossum wrote:

Please write an up-to-date short description of what you would like to see changed.

You seem to be asking me to duplicate existing effort. The essence of the desired change has been described or confirmed at least eight times already in the issue tracker.

Some of those posts are old, but not all of them are. Moreover, they are all up-to-date, because PHP-CS-Fixer's behaviour has not changed in any relevant way since they were posted.

We simply don't have the resources to go through multiple older issues to evaluate where these are still relevant and if the comments on those issues are current as well.

Luckily for you, occasionally someone (in this case, me) will perform that service for you, rather than filing yet another duplicate report and failing to link it to the existing reports about the same issue.

So, please unlock and reopen #454 for these reasons and the ones given above. Thanks.

Peace.

[SpacePossum]

Hi and thanks for getting back,

It seems I wrote my request in a confusing matter. It is great to hear the request made in several tickets is still relevant to the current behavior of the Fixer. However, after scrolling through those tickets, I conclude that these tickets are out dated in other ways which is very important to us.

First of, not all of the actors in those tickets are still active or interested, then not all comments in those tickets are still of value and the _internal_ workings of the fixer have change a lot since.

We can easily overcome these issues by having a new ticket as it will attract the people currently working on the project, the discussion will focus on the current code base and the maintainers have an easier job by just looking at what the community is discussing now (appose to reading through all closed issue as well). It will also help people that are new to matter to quickly get acquainted with it.

I understand the annoyance of what seems duplicate effort, but with your knowledge on the requested feature and after screening through all the old items, the new description will be greatly enhanced. There is no need to worry about duplicate tickets over closed ones as long there is still something that can be done.

The way we work might not always be very clear, maybe not like other projects and not following a standard. It is the result of people working together to figure out a way to keep this project going.
Not going back to old tickets and by that notifying people, is one of the things that come from that. Another is that we processing only work that has an open PR with a clear description for anyone to see, or a PR without it but than has open issue linked to it with a clear description, open for all to see.
I still feel this is not to much to ask. As such the request for the reopening of 454 will not be honored by me, because I see no reason why to not handled it like any other request.

[ghost]

@SpacePossum wrote:

I understand the annoyance of what seems duplicate effort

If so, then you would not keep insisting upon it :/

with your knowledge on the requested feature and after screening through all the old items, the new description will be greatly enhanced.

I'm sorry, but it would not. There really is nothing significant that I could say on the matter that has not already been reported by me or by others.

not all of the actors in those tickets are still active or interested

Bug reports are about issues, not about people. A bug does not disappear if the reporter does.

In this case, the bug is still present, even if some or all of the people who previously reported it are not longer active on the bug tracker. As such, the bug's original ticket (#454) should be kept open.

then not all comments in those tickets are still of value

I'm not sure I understand this remark. Generally, bug report threads often end up with a few off-topic comments but these do not, in themselves, invalidate the bug report. Only if the overwhelming majority of comments in a thread were off-topic (or offensive, etc) could I see value in closing it and starting afresh, but that is not the case here.

Anyhow, unnecessary, unlinked duplicate issue reports are of even less value than old comments in a thread about an issue that still exists.

The former literally add nothing but cruft. The latter provide historical context that can be helpful.

and the internal workings of the fixer have change a lot since.

As I stated above, "PHP-CS-Fixer's behaviour has not changed in any relevant way since [the earlier reports] were posted." Otherwise, the issue would not still be manifesting in the same way as it did when those earlier reports were created.

Put differently: what does it matter if Fixer has been refactored, in the intervening period, so as to preserve the reported, problematic behaviour? That does not invalidate or outdate an issue report about that behaviour.

a new ticket ... will attract the people currently working on the project

That seems to suggest that the project maintainers are solely using the GitHub issue tracker's default sorting order (Sort > Newest). The fix would be for the project maintainers to use the issue tracker's Sort > Recently updated feature instead.

(N.B. The sort order used to be a per-user "sticky" option, which was great, but GitHub changed that a few years back. Here is an open bug report about that, with a partial workaround: https://github.com/isaacs/github/issues/241 .)

[ntzm]

A lot of effort is being used to discuss what can simply boil down to leaving a 👍 on #2011 and maybe helping with a PR

[ghost]

@ntzm, #2011 is yet another duplicate of #454. Well spotted. I have now marked it as such and requested that it be closed accordingly.

[keradus]

@sampablokuper , I can see that you are really in need of this feature ! That's really great, now, instead of posting "i want it", "do that", "go there", spend half of that time and come help us by proposing a PR ! :)

[ghost]

@keradus wrote:

I can see that you are really in need of this feature ! That's really great

Actually, no, I am not. I rapidly made a workaround. If #454 is reopened, I will gladly post the workaround there.

However, a fix for #454 would be a very good thing to have, becase the current behaviour looks buggy from a UNIX- or POSIX-like standpoint. In that context, it violates POLA. As such, it is an important issue and the bug report for it (#454) should not be closed until the issue is fixed.

instead of posting "i want it", "do that", "go there", spend half of that time and come help us by proposing a PR ! :)

Thanks for the suggestion, but if I had developed a patch that was ready to file, I would have opened a PR already. First, though, I am (evidently) more concerned that the issue should not be dismissed, nor its discussion needlessly fragmented across duplicate reports. This would enable a linear discussion of the issue to occur in order to determine what the appropriate content of such a PR would be.

In any case, if I were to file a PR, it would be against #454 because that is the original report of the issue, and I would want #454 to be unlocked and open before filing the PR, so that #454 could be closed by that PR if it were merged, per standard good practice.

For these reasons, and all the ones given above, please unlock and reopen #454. Thanks.

[keradus]

Actually, no, I am not. I rapidly made a workaround. If #454 is reopened, I will gladly post the workaround there.

OK, so you are showing up at new repo you were never present before, ignore ppl's request to follow the way we are having here to ease our work, you are trying to enforce your way of work, calling lack of feature a bug also isn't helpful, as we never claimed we have such feature, and ultimately setting up some conditions to us.
Together with SpacePossum we were trying to guide you how we can bring a topic from death, but that's enough for me. Sorry, but I simply refuse to read more comments of your that all can be expressed by single statement "this feature would be nice to have, yet sadly I cant help bringing it". This is super counter-productive.