Not yet ready for public beta [closed]

Question

Last week, I mentioned:

This private beta needs to demonstrate that a dedicated site opens the door for questions that can't survive on our flagship site.

In order to evaluate the site on those terms, I categorized each and every question base on which site I think it should be asked on:

Site              Count Percent
----              ----- -------
Emacs                63  41.18%
SO                   51  33.33%
TeX                  16  10.46%
Unix                 12   7.84%
Apple                 3   1.96%
Ubuntu                5   3.27%
Super User            2   1.31%
Network Engineering   1   0.65%

Total               153 100.00% 

If you want to compare notes, take a look at the spreadsheet I used. Note that I did not try to guess whether the questions would be closed, downvoted, left unanswered, etc. I erred on the side of assuming that Stack Overflow would take questions about using Emacs as an IDE as well as Emacs Lisp questions. I also spot checked 28 of the questions I categorized as SO, and found 18 had been answered there. (While some were the same question phrased differently, others getting at the same underlying issue. It's a judgment call.)

The upshot is that I see 63 questions on this site that would have no home on another site on the network. Reading the answers, the quality of content ranks up there with the best on the network. I personally have learned a lot about Emacs already just reading through other peoples' questions. Everything looks good so far. Keep up the good work.

However, we aren't quite yet ready to move this site into public beta. We'd like another week to see a bigger sample of questions that belong on Emacs.SE and this site alone. Now is the time to ask your Emacs questions, especially if they are unrelated to using Emacs as an IDE or a shell.

Answer 1

First of all, I agree that we're not ready for public beta: right now the quality and complexity of the questions and answers is rising, and I think it's totally worth waiting some more.

Second, I'm a pure "answerer". I don't intend to ask questions in the foreseeable future, because this workflow doesn't work as well as IRC for me. So my point of view is strongly biased.

Now, I would like to challenge a bit the evaluation criteria. To me, it is essential to incorporate factors like:

• the fact that questions actually get answered
• how quickly they are answered
• the quality of the answers

The fact that there is potentially another home for the questions doesn't mean that they'd be treated equally there (and that goes both ways).

And I'm not saying it's easy to incorporate those factors. Actually I think it's probably awfully difficult. But it's too important to be ignored in a serious evaluation.

Let me take 2 examples of questions that have been "answered" in SO:

1. Disable ido-use-filename-at-point under specific cases
2. How to achieve code folding effects in Emacs?

The first one is a low-quality answer that's way too specialized to be generally useful (and wasn't accepted).

The second one (scored at 94 and accepted) is explaining how the feature is unneeded. I have no idea how that could satisfy anybody looking for a real answer (even a "that's not possible" would be more acceptable). And seriously, code folding is not needed? That's rather short-sighted.

In both cases, I strongly think we can do better (and actually did) here.

I don't intend to do a full analysis, but I strongly suspect there is a pattern of sub-optimal answers that I think we have a chance of avoiding here. The reason is simply that the density of people who deeply care about Emacs, and want to provide the right answer is bound to be higher here (as you said, Emacs is a way of life, not a tool :))

Then there are the unanswered questions. I was surprised at first to see that Accessing remote tags file with Emacs was asked and not answered, despite it being fairly straightforward. And then I remembered my experience of the last 2 weeks.

Since I committed to the private beta, I resumed a bit my activities on SO, on the Emacs tag. And that was painful. I cannot really quantify it, but if feels so noisy, so unfocused, that I really wouldn't want to go there on a regular basis to answer questions. As soon as the beta started, I happily gave up, and don't intend to go back.

Maybe there are more like me, who feel much more comfortable browsing randomly new questions or unanswered ones, without any additional filter (therefore without relying on any imperfect classification), because they feel like there's always a good chance they'll be able to answer. If that's the case, that means emacs.se brings value that nothing else can. Which would be good news.

And maybe it doesn't matter at all, maybe the numbers are in favor of SO, and maybe the fact that answers are not necessarily true to "the Emacs way" is of relatively little importance for those who ask. I just don't think so :)

Answer 2

This may be a terrible place for it, but I will jump in with my two cents about a benefit that Emacs.SE can provide, but has not been mentioned yet: Moderation.

Emacs questions on any other SE site are almost guaranteed to be moderated by non-emacs users. This includes not only site moderators, but the review queue as well. For example, I made (what I considered to be) a helpful edit to a SO post that has helped me in the past. My init.el recently broke, and I had a link to this SO post as being the source of the (now broken) code.

I was able to do some investigation and find a solution to the problem. I decided that I would help others out who might come back to that post, like I did, when their init files broke. I submitted a concise edit that fixed the problem, and I provided a link to the GitHub issue where the problem was discussed. However, much to my dismay, my edits were quickly rejected as "not correct."

I visited the profiles of the users who rejected my edits and found that they knew nothing about emacs. At least, their activity on SO did not show any activity on emacs/elisp related tags. I realize that this can happen on any SE site just by dumb luck, but I was amazed how quickly my edit was shot down as "not correct" despite the fact that I provided a link to an "official" answer from the package developer.

This sort of poor moderation in the past has led me to lose heart in participating in small SO "minority" communities. I was very active on the Matlab tag for a while on SO, but eventually got tired of being moderated by people who knew nothing about Matlab.

If Emacs.SE does not survive, and you are looking for ways to make the Emacs community feel more at home on SO, then please make it so that Emacs questions can only be moderated by somebody who has some rep points in the Emacs-related tags.

Answer 3

If you don't mind, I'd like to kindly criticize the TeX related choices which have been made.

The following questions have been filed under tex, but they're not about LaTeX at all. You can unarguably bump the "emacs" count by 3.

• How to view and edit pdf files in emacs?
• Why is my function not identifying the end of the region correctly?
• New line in Title of an org-mode exported html document.

These two are also plainly and clearly not LaTeX questions. Despite the title,they only mention an example use-case where LaTeX is involved. In fact, I could have included them in the list above, but I'm trying to do this very cleanly.

• Emacs function to convert an arbitrary ORG PROPERTY into an arbitrary string
• Overriding fill-paragraph in LaTeX mode

These two involve LaTeX. But the relationship is so marginal they run a decent risk of being considered off-topic at tex.se. I'd find it very hard to say they "have a home there".

• How can I preview TeX formulas inline in arbitrary modes?
• Exporting beamer with org-mode

The following three are probably on-topic at tex.se, but the elisp involved is advanced enough they would very likely go unanswered (unless one happened to run into one of the auctex developers). Should we call that "having a home"?

• controlling display of latex equations in org-mode
• Aligning multi-lined equations and tables in latex-mode
• See LaTeX code and math preview at the same time with preview-latex

The following can be regarded to have a home on either sites.

• How to call pdflatex under TeX-PDF-mode?
• Speed up TeX-insert-macro on \input
• Predictive mode, Auctex not playing nicely
• How can I hide/display LaTeX section just like org-mode does with headlines?
• Do I use preview-latex correctly?
• TOC of tables for org-mode long tables

---

It seems that any question with so much as a brief mention to tex was filed under that category, but most of them (yes, most) do not have a home on that site. The emacs count can be bumped up by 5 without a second thought, and even 10 if we're being sensible.

To clarify, I'm not saying there are 5-10 which simply should be in emacs, I'm saying these questions have no place in tex.se.

I noticed the focus of this was more heavily on stack overflow and programming questions. But it's important to remember LaTeX represents a good chunk of emacs usage.

Hopefully I didn't come off as angry. Just trying to help.

Answer 4

Thanks for taking the time to quantify this.

StackExchange sites work because they attract experts. I think that many 'IDE' or 'TeX' questions regarding Emacs are often answered most effectively by people with a good understanding of Emacs.

For example, in this TeX question on Emacs.SE, the user was able to solve their problem as a result of help with Emacs debugging. You may not have as many users with elisp debugging knowledge on TeX.SE.

This is not a criticism of the excellent TeX.SE site, just observing there's an intersection problem here.

Answer 5

I don't know whether or not we should move to a Public Beta yet so I won't comment on that.

Like Sigma I am mostly/solely an "answerer". Up until now I'd mostly restricted myself to org-mode questions on SO and SU, with an occasional glance at emacs. I've found most of my answers through Google in the past (which did lead to SO fairly often).

I would like to see more of the org-mode questions end up on emacs.se since I feel that would be a better place for them. When I was keeping up with questions on a daily basis there would be occurences of org-specific questions being sent to tex.se because they mentioned latex or pdf, yet were specifically about org-export-to-latex export. Since I had no rep on tex.se I could not comment or push for them to be moved back. Questions also end up split betwen SO and SU with the majority on SO, mostly because there is a stronger org-mode community there to answer the questions.

Drawing questions regarding org-mode,ess,magit or any other larger package to emacs.se will both increase traffic on the site, and ensure that questions about emacs-packages are answered in an Emacs context, not looked at by their other tags (tex,git,statistics) where it may provide an answer, but not provide an actual solution.

In the org-export-to-latex question, the answers mostly focused on how to modify the .tex file to add the required information, when the solution would have been to modify org #+HEADER: arguments or #+EXPORT: options.

---

Like Malabarba I have a few disagreements on the classifications:

Those are all (from what I can remember when looking at them) regarding emacs-specific keybindings/shell processes/tramp access. They may be making reference to shell/term/TRAMP but within an Emacs framework.

Sending them to Unix would not improve the answers, sending them to SO would probably have a few sent to SU (Configuration of Eshell / Overriding Keybindings). Having them in emacs.se ensures an emacs-centric view to them as opposed to emacsshellterm where you might get someone with more experience with Shell/Term but less with emacs.

Specifically for Configuration of eshell. Running programs from directories in PATH env variable, there is

• A Linux/Unix answer : Add the directory to $PATH in ~/.profile.
• A Windows answer : Add the directory to %PATH% either for the user or the system
• An Emacs answer : Add the directory to the exec-path list in Emacs.

Assuming you keep certain tools in your home directory that are cross-platform and that you only ever use from within Emacs, the third option is most portable since you only need to ensure that ~ (%HOME%) is properly mapped on Windows.

---

Another question: How does emacs manage its packages? could go to Ubuntu because it deals with that specific package manager + package.el, but it is better served as an emacs.se question since it can be ellaborated on to explain just how package.el works with regards to it's repositories, EmacsWiki .el files and third-party packages to manage packages (cask and el-get for retrieval, use-package for configuration/loading).