3

I'm thinking of questions like the following: Magit pushing / pulling show progress

Such a question could well be a feature request sent to magit's bug tracking system or mailing list, and as such doesn't necessarily belong to emacs.SE.

On the other hand, since Emacs customization is all about developing yourself the features you want, asking how to develop a feature you wish definitely falls into the advanced emacs usage which is promoted here.

So which questions should be considered on topic? Can we define objective criteria to delimit the acceptability of questions?

1
  • The question has an obvious answer, to me. You ask SE site users for answers to questions. You don't ask them to do your coding for you. The guidelines for SO should apply to coding questions here as well.
    – Drew
    Commented Oct 2, 2014 at 3:41

2 Answers 2

Reset to default
12

I don't see how this specific question wouldn't be in scope here. It's asking “how do I do this with Magit?” There's no way to know a priori whether the answer is going to be “set magit-show-progress to t”, or “run these 10 lines of Elisp code”, or “this is impossible without rewriting Git and Magit from scratch”.

Unless it is established that the desired effect is impossible or unduly hard to accomplish with Magit, which is not the case as I post this, the request would be a support request, not a wishlist item.

More generally, most questions that would potentially be a wishlist item for Emacs or an Emacs package can be valid questions here (provided they meet general Stack Exchange requirements). That's because these questions are of the form “How do I do X with Y?”, and that's our bread and butter. Answers could be a patch to Y, or a way to configure it, or an add-on Z, or an alternative Y'. It's only if the question is fundamentally “Please add support for X to Y” that it would be inappropriate here.

-1

We get a lot of requests from communities like "Emacs" about how they can use Stack Exchange to support their fellow users. Stack Exchange works really well for technical support, as long as you're not trying to outsource your entire customer support channel to Stack Exchange.

As such, posting feature requests and bug reports for the Emacs developers would be more of a "customer service" issue than the collection of "technical support" knowledge these communities are designed to gather. As such, such posts would be off topic for this site.

2
  • 5
    It is true that it should not be encouraged to move "customer support" to StackExchange. However, I think it is important to recognise that often times a simple question was not originally indended to be a feature request or a bug report (maybe the OP did not recognise that her problem was a bug or that the functionality she is looking for is a completely new feature). Emacs is well-known for its customisability and thus for me the first logical step is to ask whether someone knows a solution or has created a snippet solving my problem.
    – elemakil
    Commented Oct 1, 2014 at 22:10
  • 4
    Only if neither is the case I'll submit a feature request or bug report. More importantly, I think that newcomers can learn a great deal from the answers posted as solutions to questions that could well be a feature request. It is one of the rare chances to analyse a contained snippet of elisp code and be able to directly interact with its auther. If, eventually, there is no posted answer and the question evolved into something worthy of a feature request, the OP should be encouraged to file that request, inlclude the link in her question and add an update once its solved.
    – elemakil
    Commented Oct 1, 2014 at 22:10

You must log in to answer this question.

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