Do not offer "wontfix" label in the default-sets #513

Open
opened 4 weeks ago by buhtz · 13 comments
buhtz commented 4 weeks ago
Collaborator

I am aware that this topic is "risky" but I am not a troll. I am serios about it.

Wish

Remove wontfix from the both default-sets when creating labels.
I do not mean to block or prohibit the explicite creation of that label.
But if a project/developer want/need to use that label it should be a conscious (and hopefully well-considered) decision.

Why

There are good and objective reason why developers choose a wontfix label for an issue. And there is good research down about that. E.g. https://doi.org/10.1109/IBF50092.2020.9034539
It is evident that there are a lot of serious causes behind a wontfix. Why not nameing the real cause then?

In communication between humans (e.g. developers) it is not so important how a message (e.g. wontfix) was meant but how it is perceived. In short: The receiving person is more important then the sender.

By receiving persons (the bug report writing people) a wontfix is taken impolite and understand as Yes, the bug is there but it won't be fixed..
Especially in FOSS community it is very important to take new contributors into a project. Using wontfix does not help here.
What would help more is to explain why the Issue is not taken into account and why it is closed. (e.g. no ressources, low priority (fixed later!), not relevant in the current stable version, ...)

I am aware that this topic is "risky" but I am not a troll. I am serios about it. # Wish Remove `wontfix` from the both default-sets when creating labels. I do not mean to block or prohibit the explicite creation of that label. But if a project/developer want/need to use that label it should be a conscious (and hopefully well-considered) decision. # Why There are good and objective reason why developers choose a `wontfix` label for an issue. And there is good research down about that. E.g. https://doi.org/10.1109/IBF50092.2020.9034539 It is evident that there are a lot of serious causes behind a `wontfix`. Why not nameing the real cause then? In communication between humans (e.g. developers) it is not so important how a message (e.g. `wontfix`) was meant but how it is perceived. In short: The receiving person is more important then the sender. By receiving persons (the bug report writing people) a `wontfix` is taken impolite and understand as _Yes, the bug is there but it won't be fixed._. Especially in FOSS community it is very important to take new contributors into a project. Using `wontfix` does not help here. What would help more is to explain why the Issue is not taken into account and why it is closed. (e.g. no ressources, low priority (fixed later!), not relevant in the current stable version, ...)
Collaborator

Thank you for the suggestion, I like it. If no one objects, I'll try to apply it as soon as I get to it.

Thank you for the suggestion, I like it. If no one objects, I'll try to apply it as soon as I get to it.
fnetX added the
codeberg
gitea-related
labels 4 weeks ago
rwa commented 4 weeks ago
Collaborator

Well, reading the stance you take in the "Why?" section:
What does removing the label actually fix? A maintainer may simply close an issue even without a wontfix label.

Of course it is good behaviour to give a reason why wontfix applies. But you won't make anyone provide a reason for the closing by removing an issue label. You can't fix a problem created by missing human interaction with a technical approach.

Well, reading the stance you take in the "Why?" section: What does removing the label actually fix? A maintainer may simply close an issue even without a `wontfix` label. Of course it is good behaviour to give a reason why `wontfix` applies. But you won't make anyone provide a reason for the closing by removing an issue label. You can't fix a problem created by missing human interaction with a technical approach.
Poster
Collaborator

A maintainer may simply close an issue even without a wontfix label.

It is not the "goal" to prevent closing the issue.
It is more the opposite because "wontfix" does not mean close.

The goal is to make the opener or maintainer think about if it can stay open or not and why.

Removing the label from the defaults fix that the codeberg users do not think about it when creating a new label set. It is the same with master branches in git. Most of the people, even me, never thought about it what it can be understood by some people (not meant!).

The message for new developers is: It is not OK to use wontfix. It is tradition. If you want to use wontfix there is something wrong and you should step back and think a bit more.

You can't fix a problem created by missing human interaction with a technical approach.

Exactly! What is the problem? This is the question each developers should ask her-/himself at this point. Make them think about it is the goal.
It is that wontfix is missused as a all others or misc category. Just look at the wontfix Issues here in this repository. None of them is a real wontfix.

Fact is that wontfix is taken inpolite on an emotional level and also missunderstood by users/reports as "There is a bug but no one is interested in." Humans are emotional animals. That is nothing you can change but you have to take into account - like marketing people always does.

The point is that it often is not a bug. It is just a problem reported the wrong way (to complex problem that could be separated into more atomic issuses) or missunderstood by the opener.

If nothing else is done with an Issue (what wontfix implies) than you can close it.

If it is an often reported "problem" just because the users missunderstand something or an often asked "feauter request" which is against the design philosophy of the maintainers point them to the FAQ/Wiki section explaining it and close the report/issue.

> A maintainer may simply close an issue even without a `wontfix` label. It is not the "goal" to prevent closing the issue. It is more the opposite because "wontfix" does not mean close. The goal is to make the opener or maintainer think about if it can stay open or not and **why**. Removing the label from the defaults fix that the codeberg users do not think about it when creating a new label set. It is the same with `master` branches in git. Most of the people, even me, never thought about it what it can be understood by some people (not meant!). The message for new developers is: It is not OK to use `wontfix`. It is tradition. If you want to use `wontfix` there is something wrong and you should step back and think a bit more. > You can't fix a problem created by missing human interaction with a technical approach. Exactly! What is the problem? This is the question each developers should ask her-/himself at this point. Make them think about it is the goal. It is that `wontfix` is missused as a `all others` or `misc` category. Just look at the `wontfix` Issues here in this repository. None of them is a real `wontfix`. Fact is that `wontfix` is taken inpolite on an emotional level and also missunderstood by users/reports as "There is a bug but no one is interested in." Humans are emotional animals. That is nothing you can change but you have to take into account - like marketing people always does. The point is that it often is not a bug. It is just a problem reported the wrong way (to complex problem that could be separated into more atomic issuses) or missunderstood by the opener. If nothing else is done with an Issue (what `wontfix` implies) than you can close it. If it is an often reported "problem" just because the users missunderstand something or an often asked "feauter request" which is against the design philosophy of the maintainers point them to the FAQ/Wiki section explaining it and close the report/issue.
rwa commented 4 weeks ago
Collaborator

Thank you for your explanation. Maybe i'm stubborn but i still don't get why removing a label should improve the situation.

The goal is to make the opener or maintainer think about if it can stay open or not and why.

How does removing a label make people think? If they apply the defaults without thinking about it, they won't start thinking about if a label is missing, they will close issues right away.

Just look at the wontfix Issues here in this repository. None of them is a real wontfix.

I disagree.

I don't object to removing the label from the defaults, but from my point of view it will not help anybody.

Thank you for your explanation. Maybe i'm stubborn but i still don't get why removing a label should improve the situation. > The goal is to make the opener or maintainer think about if it can stay open or not and why. How does removing a label make people think? If they apply the defaults without thinking about it, they won't start thinking about if a label is missing, they will close issues right away. > Just look at the wontfix Issues here in this repository. None of them is a real wontfix. I disagree. I don't object to removing the label from the defaults, but from my point of view it will not help anybody.
Collaborator

Are there blog articles or other resources investigating this topic?

I usually don't like discussing a topic from the beginning, but rather reading through resources other people already shared; they often took more points into consideration and have more experiences whether something works out or not.

So if there are any, I'd love to read through them before discussing here.

Are there blog articles or other resources investigating this topic? I usually don't like discussing a topic from the beginning, but rather reading through resources other people already shared; they often took more points into consideration and have more experiences whether something works out or not. So if there are any, I'd love to read through them before discussing here.
Poster
Collaborator

Are there blog articles or other resources investigating this topic?

https://doi.org/10.1109/IBF50092.2020.9034539

This is a well done scientific research investigating the real reasons behind wontfix in real projects.

If you do not have a liecence to access this article you can ask the author himself via "request full text".
https://www.researchgate.net/publication/339977136_Why_Is_My_Bug_Wontfix

> Are there blog articles or other resources investigating this topic? https://doi.org/10.1109/IBF50092.2020.9034539 This is a well done scientific research investigating the real reasons behind `wontfix` in real projects. If you do not have a liecence to access this article you can ask the author himself via "request full text". https://www.researchgate.net/publication/339977136_Why_Is_My_Bug_Wontfix
Poster
Collaborator

Thank you for your explanation. Maybe i'm stubborn but i still don't get why removing a label should improve the situation.

You self describing the improvment. ;)

How does removing a label make people think? If they apply the defaults without thinking about it, they won't start thinking about if a label is missing, they will close issues right away.

Not using wontfix and keep the issue open BUT simply closing it still implicates thinking. There is nothing wrong with closing. It is good when closed. There is nothing good about keep an Issue open when no one will work ever(!) work on it (I mean not now and not in the future. Never.).

Another siutation could be that a repository owner ask her-/himself where the f*** is my wontfix label. Then the dev need to act explicte and create that lable or think of different labels. The point is that the dev is forced to act concisous.

Of course not everyone will think deep (enough). Even if they do they maybe they won't stop to use wontfix. It needs a cultural change. This will take years or decades and removing a missused and missunderstood bug-label from a default-setting is just a beginning.

I am looking forward if some people will open an issue about adding the label to the defaults. ;)

> Thank you for your explanation. Maybe i'm stubborn but i still don't get why removing a label should improve the situation. You self describing the improvment. ;) > How does removing a label make people think? If they apply the defaults without thinking about it, they won't start thinking about if a label is missing, they will close issues right away. Not using `wontfix` and keep the issue open BUT simply closing it still implicates _thinking_. There is nothing wrong with closing. It is good when closed. There is nothing good about keep an Issue open when no one will work ever(!) work on it (I mean not now and not in the future. Never.). Another siutation could be that a repository owner ask her-/himself where the f*** is my `wontfix` label. Then the dev need to act explicte and create that lable or think of different labels. The point is that the dev is forced to act concisous. Of course not everyone will think deep (enough). Even if they do they maybe they won't stop to use `wontfix`. It needs a cultural change. This will take years or decades and removing a missused and missunderstood bug-label from a default-setting is just a beginning. I am looking forward if some people will open an issue about adding the label to the defaults. ;)

Other research papers on the subject:

Other research papers on the subject: - "Analysis of Software Repositories Using Process Mining" http://www.ttcenter.ir/ArticleFiles/ENARTICLE/3660.pdf - "“Won’t We Fix this Issue?” Qualitative Characterization and Automated Identification of Wontfix Issues on GitHub" https://arxiv.org/abs/1904.02414
Collaborator

I had one thought: may i wana assign wontfix here 😆

seriously - it was used here too: https://codeberg.org/Codeberg/Community/issues?labels=108

so for what default configs there should be can be debated a lot ... sep. on topics with mouch opinions and no real binary consens on a thing.

since it's gitea's default here i would just leave it

if a project maintainer just put this lable on an issue you should kindly ask the reason if he did not had the time to do wrote one - else i think that project is not healthy maintaind anyway ...

EDIT: so can we propose to fix the description of that wontfix to match what it is used here ?!?
EDIT: EDIT: I think we can rm it if realy intended

I had one thought: may i wana assign `wontfix` here 😆 ~~seriously - it was used here too: https://codeberg.org/Codeberg/Community/issues?labels=108~~ so for what default configs there should be can be debated a lot ... sep. on topics with mouch opinions and no **real binary** consens on a thing. since it's gitea's default here i would just leave it if a project maintainer just put this lable on an issue you should kindly ask the reason if he did not had the time to do wrote one - else i think that project is not healthy maintaind anyway ... EDIT: so can we propose to fix the description of that wontfix to match what it is used here ?!? EDIT: EDIT: I think we can rm it if realy intended
Poster
Collaborator

since it's gitea's default here i would just leave it

OK for me. I am not brave enough to bring this topic up in the gitea community. :D

EDIT: so can we propose to fix the description of that wontfix to match what it is used here ?!?

OK, but where?

EDIT: EDIT: I think we can rm it if realy intended

"rm"`?

> since it's gitea's default here i would just leave it OK for me. I am not brave enough to bring this topic up in the gitea community. :D > EDIT: so can we propose to fix the description of that wontfix to match what it is used here ?!? OK, but where? > EDIT: EDIT: I think we can rm it if realy intended "rm"`?
Collaborator

"rm"`?

=delete

>"rm"`? =delete
Collaborator

@buhtz thanks for posting this, I have requested a copy of the paper from the authors. I am always interested in reading about scientific studies on things such as this.

@buhtz thanks for posting this, I have requested a copy of the paper from the authors. I am always interested in reading about scientific studies on things such as this.

Hi folks. I'm new here and this is my first comment. I'm all about problem statements these days so allow me to reformulate:

Problem: Supplying wontfix as a default label encourages its use and may have a dampening effect on development community culture

This a problem because it reinforces a pattern that I don't consider helpful for software development: Automatic dismissal of issues while cutting conversation short.
The label's existence doesn't mean it will be used, but depending on how any default labels there are, it may be a tempting option due to it's lack of specificity.

If forking and project competition were more common, I would consider this less of a problem but there's an inertia and respect that contributors have for owners of a project which gives wontfix an outsized effect versus what may be the intent of the new repo owner.

I haven't read any of the referenced papers but wanted to give first impressions because I'm very focused on community organizing around software and want to record my thoughts before looking at evidence to see what biases I may shed.

Hi folks. I'm new here and this is my first comment. I'm all about problem statements these days so allow me to reformulate: Problem: Supplying `wontfix` as a default label encourages its use and may have a dampening effect on development community culture This a problem because it reinforces a pattern that I don't consider helpful for software development: Automatic dismissal of issues while cutting conversation short. The label's existence doesn't mean it will be used, but depending on how any default labels there are, it may be a tempting option due to it's lack of specificity. If forking and project competition were more common, I would consider this less of a problem but there's an inertia and respect that contributors have for owners of a project which gives wontfix an outsized effect versus what may be the intent of the new repo owner. I haven't read any of the referenced papers but wanted to give first impressions because I'm very focused on community organizing around software and want to record my thoughts before looking at evidence to see what biases I may shed.
Sign in to join this conversation.
No Milestone
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.