New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: populate the PriorDiscussion wiki page #18430
Comments
Perhaps there should be a section about frequently-requested features. The author of a feature request would first search this section to see if their feature has already been discussed. |
@as, yes, the Q&A could have many sections, and that would be one. |
Is there a reason not to put these in the FAQ, perhaps as a special section. FRF (frequently requested features) |
@robpike, I don't want to go through gatekeepers and English review and Gerrit for content that the community could collaborate on quickly. The goal is content and answers (or at least links to background reading), not quality of prose. Any answer for these is better than no answers (the current state). |
Sounds like a role for the wiki, not something checked in. |
Yup. |
If it helps, This sheet lists features I've frequently seen requested. The FAQ already discusses some specific feature requests (unions and concurrent map access), so It may be useful to have a link to the wiki here: |
Perhaps you could just add a new section to the existing 'Questions' page on the wiki for this? |
It sounds like you are proposing a wiki/Answers page or something. OK, LGTM. Proposal accepted. |
@kennygrant, we don't pay Github per wiki page, so no need to overload that page with multiple meanings. I've created https://golang.org/wiki/PriorDiscussion which I hope others can help me flesh out over the next few weeks. I'll repurpose this bug about adding to it. |
I propose that our new policy when closing bugs is to never say:
If two people have brought it up before, there will probably be three, and it deserves an entry in https://golang.org/wiki/PriorDiscussion . And then after adding such an entry, we should reply instead with:
|
I am am strongly in favour of this.
…On Thu, 5 Jan 2017, 08:28 Brad Fitzpatrick ***@***.***> wrote:
I propose that our new policy when closing bugs is to never say:
Sorry, no, this has been discussed before. Go search.
If two people have brought it up before, there will probably be three, and
it deserves an entry in https://golang.org/wiki/PriorDiscussion .
And then after adding such an entry, we should reply instead with:
See prior discussion at
https://golang.org/wiki/PriorDiscussion#panics-on-sends-or-closes-of-closed-channel
.
/cc @minux <https://github.com/minux> @odeke-em
<https://github.com/odeke-em>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#18430 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA_mqszlHWm6v0ziI9i0YLyD1-iJ4ks5rPA8EgaJpZM4LVcO3>
.
|
Also, if you see a good thread with good discussion or a good explanation, add it anyway, even if it's the first time you've seen it. The PriorDiscussion page can also just be an index of good discussion that's happened in the past for interested readers. |
I tried to send a change to https://golang.org/wiki/PriorDiscussion thinking that I was creating a "pull request" of some sort - to be reviewed - but it just changed the page straight away (??). Well, that's strange. BTW there's two more links now. |
No need for code review. Append at will. Thanks! |
SGTM! Thank you @bradfitz for the idea. |
This happened. |
There are many questions that aren't in our FAQ, but which people ask with some frequency.
See the recent #18425 for the latest example. It'd be nice if we could reply with a URL, instead of "search the history"
Normally additions to the FAQ are denied with the reason that the proposed new Asked Question is not Frequent.
So let's create a separate page (a wiki page, probably, so more people can edit) with many more Q&A, and link to old mailing list discussion threads and bugs, so we don't have to close bugs without pointing the author at something for them to read.
The text was updated successfully, but these errors were encountered: