6

Are questions asking for packages recommendations on topic? For example:

What's the best package for reading email in Emacs for a GMail user?

3 Answers 3

9

I believe recommendation questions should be on topic, although we should watch out for a few possible systematic problems with them.

Questions like this are frowned upon in StackOverflow, partly for being too broad. However, I feel that the world of Emacs packages is sufficiently constrained to make these questions manageable: after all, we only have a handful of web browsers and email clients ;).

I feel that this shared knowledge about packages is one of the most useful resources in the community and yet really hard to find in any centralized location. At best, you can look on Emacs Wiki and get a page that's unstructured and hard to follow.

Another worry with these sorts of questions is that answers get out of date quickly. While this is a concern for some packages, I think most change slowly enough to not make this an issue. The core set of packages and modes people recommend now does not seem that different from the core set even a few years ago.

A final issue I find concerning is subjectivity. How likely are answers to this sort of question entirely based on opinion and not useful? This is certainly something to watch out for. At the same time, it feels like the constrained set of choices will reign this in somewhat. Moreover, the community often has a strong—but frustratingly implicit—consensus driven by experience, shared anecdotes and common knowledge. Tapping into that would be eminently useful.

4

I would consider them on-topic.

Even with rapid changes in some cases, or addition of new clients, any information on packages will remain relevant since features are usually added not removed. Newer answers will include newer packages that may provide better results (subjectively).

Most of the older favorites will remain favorites, while newer packages will get further exposure by even being suggested.

This will

  • Lead to more users trying out the new packages and perhaps switching over for additional features
  • Lead to supported older packages working on including new features that are suggested by new packages if applicable
  • Help find/fix issues with the various packages (new or old) by exposing the issues.

If the answers focus on the features offered by the packages and on methods of using the package to reach the desired goal (i.e reading gmail in Emacs) anyone looking through the answers later will be able judge whether the package can do what they require (imap vs offline for example).

2

Yes, package recommendations should be on-topic. Most questions are about solving a problem. If the best way to solve a problem is to use an existing package, so be it.

This doesn't mean that any question that happens to be “what package should I use for …” is ok. The usual quality controls apply. In particular, it's common for questions that ask for package recommendations to lack information. A question like “What's the best package for reading email in Emacs for a GMail user?”, for example, is very underspecified and should be closed as unclear what you're asking. What features of Gmail are expected? Is there an expectation of interoperability with Gmail (e.g. to synchronize labels)? What protocols (local email, IMAP, …) are needed?

Some Stack Exchange sites have established a blanket ban on anything that looks like a recommendation question. This is especially the case on Stack Overflow and Super User. Rather than enforce moderation rules to keep the good questions and close the bad ones, these sites close all recommendation questions. There is a specialized Stack Exchange site for software recommendations. That site has stringent quality guidelines for both questions and answers. Moderation on SR.SE works well enough, so bad posts tend to get deleted quickly, but good answers are hard to come by. The problem on SR.SE is that most topics lack experts. It would be best to have the questions where the experts are. For Emacs packages, that's here on Emacs Stack Exchange.

I recommend applying similar guidelines to SR.SE.

  • Good recommendation questions describe both a goal or user story (I'm a … and I want to …), and some precise requirements (it must …).
  • Questions that lack information (not precise enough requirements to delimit valid answers, no endgoal to rate answers) get closed.
  • Good answers don't just say “use X”, they explain how to use X, and match the requirements in the question against the product's features.
  • Bad answers that have no value over a web search get deleted.

(Note: I'm a moderator on Software Recommendations, and I helped write the guidelines there.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .