ruby-core

Issue #9503 has been updated by Zachary Scott.


 We are working on official faq, maybe we can have another that is meant for developers.
 
 I'm afraid a Q&A submission form will just get abused, or neglected.
 
 Why create Yet Anoter Channel for committers have to pay attention to?
 
 > On Feb 9, 2014, at 12:07 AM, [email protected] wrote:
 > 
 > Issue #9503 has been updated by Yusuke Endoh.
 > 
 > 
 > I think it is a good idea, but few committers (including I) will have interest of creating it.
 > Instend of just requesting it, could you please create a draft by gathering frequent questions that matz has already answered?  Or, at least, please create a question list.
 > 
 > Thanks,
 > 
 > -- 
 > Yusuke Endoh <[email protected]>
 > 
 > ----------------------------------------
 > misc #9503: Request for a Question and Answer section
 > https://bugs.ruby-lang.org/issues/9503#change-45042
 > 
 > * Author: Tsuyoshi Sawada
 > * Status: Rejected
 > * Priority: Normal
 > * Assignee: 
 > * Category: 
 > * Target version: 
 > ----------------------------------------
 > I often come up with a question regarding why Ruby is designed the way it is with respect to a certain specification. Without knowing why it was designed in that way, I usually start to feel that such thing should be in a different way, and I ask that as a feature on this site, but then, sometimes it is responded from the developers with a reason why it has to be the way it is.
 > 
 > When I have such question, I first try to look for answers about the design decision; especially, I am a frequent user of a Question and Answer site called StackOverflow (stackoverflow.com), and whenever I ask that kind of question, it ends up with the consensus being "Ask Matz". Afterall, only Matz (or the core developers) knows.
 > 
 > So, I request a Question and Answer section on this site regarding design decisions about Ruby: Why a certain feature was designed in such way and not in another way. I think this is the right place where such thing should be because only the developers know the reason. Then, people can ask about why a certain design decision was made before posting a feature request, and that will reduce hopeless feature requests that end up being rejected. That would be of a benefit to both the developers and the people wondering about the design.
 > 
 > 
 > 
 > -- 
 > http://bugs.ruby-lang.org/

----------------------------------------
misc #9503: Request for a Question and Answer section
https://bugs.ruby-lang.org/issues/9503#change-45056

* Author: Tsuyoshi Sawada
* Status: Rejected
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
I often come up with a question regarding why Ruby is designed the way it is with respect to a certain specification. Without knowing why it was designed in that way, I usually start to feel that such thing should be in a different way, and I ask that as a feature on this site, but then, sometimes it is responded from the developers with a reason why it has to be the way it is.

When I have such question, I first try to look for answers about the design decision; especially, I am a frequent user of a Question and Answer site called StackOverflow (stackoverflow.com), and whenever I ask that kind of question, it ends up with the consensus being "Ask Matz". Afterall, only Matz (or the core developers) knows.

So, I request a Question and Answer section on this site regarding design decisions about Ruby: Why a certain feature was designed in such way and not in another way. I think this is the right place where such thing should be because only the developers know the reason. Then, people can ask about why a certain design decision was made before posting a feature request, and that will reduce hopeless feature requests that end up being rejected. That would be of a benefit to both the developers and the people wondering about the design.



-- 
http://bugs.ruby-lang.org/