Acceptable Questions and User Opinions

Question

This meta question arises from the closure of my question. I am not going to try to reopen the question, because I am not a close/reopen button lover. Just let the question be part of the silent history of TeX.SE site. What I want to know are the guidelines of TeX.SE about the relations between accepatble questions and user opinions.

Please read first all the comments below the closed question and its answers before reading forwards. Thank you.

From the closed question, I find two general questions that I want to asked here.

The First Question

Queston 1: Are questions of "how to do something with some package" acceptable on this site, if the asker knows with 90% certainty some feature is not supported in some package?

For this queston, I think the answer is YES. In general, an asker gets the certainty of whether or not some feature is supported by searching in the web or in the documentation. Sometimes, there are undocumented features in some package (for example, some months ago, an user ever asked how to break from \int_step_inline loop). Also, if the feature is really not supported, other users could still answer the question, providing some workarounds or hacks of the dirty code, which may be useful to the asker and others.

The Second Question

Queston 2: Are his/her questions acceptable on this site, if the asker believe the vote and bookmark numbers of every question are positively correlated to how many users need some feature of some package?

For this queston, I also think the answer is YES.

(1) On TeX.SE main site, users can not open polls. So every post is either question or answer, and "a disguised poll" is a meaningless statement.

(2) I will not change the above belief. So If the answer is NO, then all of my questions can be closed for this reason, which I think is ridiculous.

(3) My belief is for all questions, not only for my questions. For example, when writing my package, I sorted by votes all questions with [tables] tag. And the first three questions are

819 votes: How to add a forced line break inside a table cell
421 votes: Column and row padding in tables
289 votes: How to create fixed width table columns with text raggedright/centered/raggedleft?

So I decided these features in tables are mostly wanted by users and implemented them in my package. Everyone has his/her right to disagree with me. But I don't think it is the proper reason to close my questions.

---

I will add two answers below as polls for these two questions. Please upvote or downvote them.

Answer 1

Queston 1: Are questions of "how to do something with some package" acceptable on this site, if the asker knows with 90% certainty some feature is not supported in some package?

---

POLL

Upvote if you think these questions are acceptable.

Downvote if you think these questions are unacceptable.

Answer 2

Queston 2: Are his/her questions acceptable on this site, if the asker believe the vote and bookmark numbers of every question are positively correlated to how many users need some feature of some package?

---

POLL

Upvote if you think these questions are acceptable.

Downvote if you think these questions are unacceptable.

Answer 3

Without going too much into the general discussion, let me add some words as to why I ended up voting for the closure of your question.

You, @L.J.R., have at least two relatively large expl3-based packages on CTAN, of which at least one is known to have a sizable user base. This suggests that you are a more experienced expl3 developer than yours truly. When you asked about whether l3keys supported custom key properties, it took me more or less one minute to find the source code of l3keys and the line of code that added the .code:n property:

\cs_new_protected:cpn { \c_@@_props_root_str .code:n } #1
    { \@@_cmd_set:nn \l_keys_path_str {#1} }

It took twenty more seconds to find out that \c_@@_props_root_str expanded to key~prop~>~. From all of this, it was immediately quite clear that this was a low-level implementation using private macros. There was not even a private command like \_@@_new_key_property:npn; it was all being done manually. In other words, it was clear that it was not the developers’ intention that anyone (perhaps not even themselves) should add any more key properties.

All in all, I came to that conclusion in two minutes. As mentioned, you probably have more expl3 programming experience than I. Are you going to tell me that you hadn’t already gone through the same steps and reached the same conclusion? Or that you didn’t know how to?

If you really wanted custom key properties, why didn’t you ask a question like “Why does l3keys not support custom key properties?” in order to start a proper discussion of the thing you were actually interested in, instead of disguising the intent of the question like that? It would be as if @egreg got tired of TeX’s lack of metrics for the positioning of left superscripts and added a question like “Where are the metrics for left superscripts stored?” (which of course he would never do).

On top of that, your explicit motivation for your question was that you simply found it easier and prettier to replace .code:n by .mycode:n than to replace .code:n = by .code:n = \MyFunction in the source code of your pakcage. And in order to save yourself that bit of work, you requested a feature which, even if it was ever added, would only appear in something like 10 years?

And by the way, how would you ever avoid package clashes if packages used custom key properties with names like .mycode:n? Or did you want custom key properties only for custom key modules? The current implementation of key properties (see the code above) proves that this would require an extremely radical redesign of the underlying code of l3keys.

Answer 4

As one of the close voters I will try to address the current meta question and explain my reasoning for voting to close the question on main.

Regarding the meta question: I think the statement "some feature is not supported in some package" is often not very meaningful for LaTeX packages. Half of the questions here on the site are to extend the functionality of a package in a way not supported by the provided package macros and/or envisioned by the package author. The solution in such cases is to write additional macros or to patch existing commands to allow for the additional feature. LaTeX being extensible, all code in plain text, and limited name spaces/encapsulation means that it is almost always possible to make a package support a new feature, although it may not be easy and it may not be a good idea.

For expl3 the situation is maybe a bit different because it is an actual language rather than just a package. However, as the comments and answers on the question on main demonstrated, there are solutions/alternatives/workarounds for the requested functionality, which means it can be "supported" in a sense. Such a question and its answers are obviously fine for the site.

So to answer the meta question posed here directly: "some feature is not supported" is not really a meaningful or clear-cut criterion, and questions asking about how to do something with some package are clearly acceptable.

---

As for why I voted to close the question on main: from the discussion in comments I got the idea that the question as posed was not genuine. As Gaussler said in a comment here: there were just too many little things with that question that it no longer made any sense as a question on TeX.SX. It was "not a real question", which is no longer an official close reason (it was until a few years ago), now you could classify it as "opinion-based", as it was intended as a poll/discussion. This is not what the site is for, you can use TeX.SE chat for this or a relevant mailing list or the issue tracker of expl3.

For a new user that accidentally mixes some opinion-based aspect with an actual how-to question this can be overlooked, but a high-rep user should adhere more strictly to the Q&A format in my opinion.