The nice thing about discuss-before-implement is that, as Alan Kay once said, "Perspective is worth 30 extra IQ points." Getting the suggestions and complaints from others may reveal that one's original plan was either mistaken or incomplete, and points the way toward a better solution.
The mailing list is an excellent filter. With things like github, people subscribe to a pet peeve, and ignore everything else. That selects for people who are fixated on one thing, but do not give a shit about anything else--including other users. Someone who stays subscribed to the mailing list has to at least glance through all discussions--even ones regarding features they don't care about. That means a) they care enough to devote that much sustained attention to mutt, and b) they have some context for on-going development ( strengths, weaknesses, bugs, history, goals, etc). >> We should make it clear to users that the correct way to request a >> feature is not to open an issue, but to contact the developers through >> the mailing list and discuss it beforehand. Only after it is discussed >> and agreed on that it's worth having it as a feature request someone >> should open an issue. >> > ehm. > "let's make it as hard as possible. hopefully this will discourage people from > actually doing it." On 26-01-12 14:52, Oswald Buddenhagen via Mutt-dev wrote: > On Mon, Jan 12, 2026 at 01:17:50PM +0100, Rene Kita wrote: > > The issue tracker should only have open items that are confirmed bugs or > > bug reports being triaged and feature requests where someone agreed to > > work on. > > > says who? > > i for one think that a feature request that has been closed is a clear "not > welcome here, don't bother" message. adding a comment that says the opposite > is just confusing. > > i'm fairly sure that a significant portion of people, if not the majority, > feels that way. in fact, my impression is that the only ones who ever argue > differently are some (de-facto ex-)maintainers. > > > Closing these issues will notify the issuer. This allows complaining > > about it. If no one complains, it's not that important. > > > my experience with actual implementations of such policy is that no-one who > has the rights will bother re-opening such issues - after all, that would > mean acknowledging that something *should* be done, and who wants _that_ > feeling? not closing the issue in the first place has the same psychological > effect, but the inhibitions are higher, because closing would be an active > action. > > > Also with a lack of manpower saying 'patches welcome' is a valid option. > > > sure it's valid as such, but one shouldn't send mixed messages about how > welcome a patch would _really_ be. > > as i said in the issue arnt is referring to, the correct way to handle > things is to add labels which indicate the issue type and the importance. > one can go beyond that and have explicit needinfo, helpwanted, etc. labels. > there is no shortage of projects which demonstrate that. > > the act of adding such labels is sufficient feedback for the reporter that > the issue was looked at and what to expect. > > > We should make it clear to users that the correct way to request a > > feature is not to open an issue, but to contact the developers through > > the mailing list and discuss it beforehand. Only after it is discussed > > and agreed on that it's worth having it as a feature request someone > > should open an issue. > > > ehm. > "let's make it as hard as possible. hopefully this will discourage people > from actually doing it." > also, how exactly does that solve the issue under discussion? under the > protocol arnt now implemented, such issues would still expire.
