Skip to main content
Cross Validated

Return to Answer

replaced http://meta.stats.stackexchange.com/ with https://stats.meta.stackexchange.com/
Source Link
Community Bot
Community Bot
  • 1
replaced http://meta.stats.stackexchange.com/ with https://stats.meta.stackexchange.com/
Source Link
Community Bot
Community Bot
  • 1

I imagine that "desirable" rather than "necessary" is the key word here.

Nick Cox has eloquently describedhas eloquently described both:

  1. The reason many [feature-requests] get declined without comment; and
  2. Whether or not a comment or explanation is required on a declined [feature-request].

Lots of good feature requests get tagged [status-declined] because while they are good ideas that many people on the site would probably use, they aren't strictly necessary. While our development team is growing, we still have enough of a staffing shortage that we've got to perform a significant amount of triage on [feature-requests].

So that's why those three were probably declined. I'll try and look into them further and see if there's any documentation anywhere about when they were discussed and what (if anything further) was decided.

In general, leaving an explanation is not required, but extremely desirable. Moderators and employees have the ability to use the [status-*] tags without commenting or leaving answers, but it's annoying and confusing for the other users, so we should try to avoid it.

I imagine that "desirable" rather than "necessary" is the key word here.

Nick Cox has eloquently described both:

  1. The reason many [feature-requests] get declined without comment; and
  2. Whether or not a comment or explanation is required on a declined [feature-request].

Lots of good feature requests get tagged [status-declined] because while they are good ideas that many people on the site would probably use, they aren't strictly necessary. While our development team is growing, we still have enough of a staffing shortage that we've got to perform a significant amount of triage on [feature-requests].

So that's why those three were probably declined. I'll try and look into them further and see if there's any documentation anywhere about when they were discussed and what (if anything further) was decided.

In general, leaving an explanation is not required, but extremely desirable. Moderators and employees have the ability to use the [status-*] tags without commenting or leaving answers, but it's annoying and confusing for the other users, so we should try to avoid it.

I imagine that "desirable" rather than "necessary" is the key word here.

Nick Cox has eloquently described both:

  1. The reason many [feature-requests] get declined without comment; and
  2. Whether or not a comment or explanation is required on a declined [feature-request].

Lots of good feature requests get tagged [status-declined] because while they are good ideas that many people on the site would probably use, they aren't strictly necessary. While our development team is growing, we still have enough of a staffing shortage that we've got to perform a significant amount of triage on [feature-requests].

So that's why those three were probably declined. I'll try and look into them further and see if there's any documentation anywhere about when they were discussed and what (if anything further) was decided.

In general, leaving an explanation is not required, but extremely desirable. Moderators and employees have the ability to use the [status-*] tags without commenting or leaving answers, but it's annoying and confusing for the other users, so we should try to avoid it.

Source Link
hairboat Staff
hairboat Staff
  • 101
  • 8

I imagine that "desirable" rather than "necessary" is the key word here.

Nick Cox has eloquently described both:

  1. The reason many [feature-requests] get declined without comment; and
  2. Whether or not a comment or explanation is required on a declined [feature-request].

Lots of good feature requests get tagged [status-declined] because while they are good ideas that many people on the site would probably use, they aren't strictly necessary. While our development team is growing, we still have enough of a staffing shortage that we've got to perform a significant amount of triage on [feature-requests].

So that's why those three were probably declined. I'll try and look into them further and see if there's any documentation anywhere about when they were discussed and what (if anything further) was decided.

In general, leaving an explanation is not required, but extremely desirable. Moderators and employees have the ability to use the [status-*] tags without commenting or leaving answers, but it's annoying and confusing for the other users, so we should try to avoid it.