Thread: Direct links to edit documentation
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/runtime-config-wal.html Description: Would it be possible to add "edit this page" links to every PostgreSQL doc page, pointing to the docs git repo, ideally on a site that allows on-the-site editing without locally cloning i.e. github? This will make it far easier to contribute tiny changes like adding more links in the text. For example, https://www.postgresql.org/docs/12/runtime-config-wal.html has a lot of useful information, but many setting keywords are not links, making it harder to find. Commenting on that page that a link is missing seems silly, whereas if there was an edit button, users could have submitted their edits directly. Thanks!
On Wed, Apr 29, 2020 at 04:36:37PM +0000, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/runtime-config-wal.html > Description: > > Would it be possible to add "edit this page" links to every PostgreSQL doc > page, pointing to the docs git repo, ideally on a site that allows > on-the-site editing without locally cloning i.e. github? This will make it > far easier to contribute tiny changes like adding more links in the text. > For example, https://www.postgresql.org/docs/12/runtime-config-wal.html has > a lot of useful information, but many setting keywords are not links, making > it harder to find. Commenting on that page that a link is missing seems > silly, whereas if there was an edit button, users could have submitted their > edits directly. Wow, that sounds like a nice idea, but I have no idea how to do that. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
ElasticSearch also uses AsciiDoc with the "edit_me" module that generates those. Code - https://github.com/elastic/docs/blob/master/resources/asciidoctor/lib/edit_me/extension.rb
It results in a semi-transparent "edit me" button at the top to the right of the page title, e.g. https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-geotilegrid-aggregation.html
On Wed, Apr 29, 2020 at 1:27 PM Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Apr 29, 2020 at 04:36:37PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/12/runtime-config-wal.html
> Description:
>
> Would it be possible to add "edit this page" links to every PostgreSQL doc
> page, pointing to the docs git repo, ideally on a site that allows
> on-the-site editing without locally cloning i.e. github? This will make it
> far easier to contribute tiny changes like adding more links in the text.
> For example, https://www.postgresql.org/docs/12/runtime-config-wal.html has
> a lot of useful information, but many setting keywords are not links, making
> it harder to find. Commenting on that page that a link is missing seems
> silly, whereas if there was an edit button, users could have submitted their
> edits directly.
Wow, that sounds like a nice idea, but I have no idea how to do that.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
I see how that can be pretty useful for something that's as simple as asciidoc. But I wonder how useful it would be for our docbook documentation.
There'd be no preview (which there i sin the elastic), and we know how difficult it can be to get the tags right without running test builds even for those that are used to working in the system.
Though if what we're considering are basically drive-by typo fixes and such, those would probably work in a scenario like that, since you're unlikely to need a preview or break a build.
Another complication would be that we don't have a 1-1 mapping between source files and output URLs. So you'd have to find some way to track it back to the exactly right portion of the source file. This would probably be possible if we were to do it as a feature on our own site (and not just a source-edit-on-github-style), but it would probably ont be a trivial piece of work. Question is if the benefit would outweigh the cost, compared to just receiving comments and "manually patching them in".
//Magnus
On Wed, Apr 29, 2020 at 11:39 PM Yuri Astrakhan <yuriastrakhan@gmail.com> wrote:
ElasticSearch also uses AsciiDoc with the "edit_me" module that generates those. Code - https://github.com/elastic/docs/blob/master/resources/asciidoctor/lib/edit_me/extension.rbIt results in a semi-transparent "edit me" button at the top to the right of the page title, e.g. https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-geotilegrid-aggregation.htmlOn Wed, Apr 29, 2020 at 1:27 PM Bruce Momjian <bruce@momjian.us> wrote:On Wed, Apr 29, 2020 at 04:36:37PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/12/runtime-config-wal.html
> Description:
>
> Would it be possible to add "edit this page" links to every PostgreSQL doc
> page, pointing to the docs git repo, ideally on a site that allows
> on-the-site editing without locally cloning i.e. github? This will make it
> far easier to contribute tiny changes like adding more links in the text.
> For example, https://www.postgresql.org/docs/12/runtime-config-wal.html has
> a lot of useful information, but many setting keywords are not links, making
> it harder to find. Commenting on that page that a link is missing seems
> silly, whereas if there was an edit button, users could have submitted their
> edits directly.
Wow, that sounds like a nice idea, but I have no idea how to do that.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
> On 4 May 2020, at 19:06, Magnus Hagander <magnus@hagander.net> wrote: > Question is if the benefit would outweigh the cost, compared to just receiving > comments and "manually patching them in". Another question is the cost of managing access to such a system, we haven't exactly had the best of luck with input from interactive systems in the past. Is a community login enough or does it need an extra bit like the Wiki? Just thinking out loud of the costs involved which need to be offset. cheers ./daniel
Daniel and Magnus, thanks for your replies. Here's my personal 2-click submission "ideal scenario", that may differ from other contributors, but seems to be very common now for many FOSS projects. I think this will work for the vast majority of the documentation pages. Note that this is not a wiki-style editing, but a proper pull request process subject to maintainer's review.
* While viewing the "CREATE TABLE" page [1], I click some "edit" button (e.g. in the upper right corner)
* It takes me to the GitHub "edit" page [2] (this is the link target of the gray pencil icon on page [3] - upper right corner on gray background)
* I edit the page -- the syntax seems trivial enough for the vast majority of non-structural edits. I can add more examples, improve grammar, add links, etc.
* I click "Propose file changes" at the bottom. This automatically will create a fork of the repo, and create a pull request into the main Postgres github repo.
* (automated step) some bot creates a PR against the primary Postgres repo, submitting the change.
* Maintainers review and merge the change.
Now, I do see that https://github.com/postgres/postgres is not the primary repo, and that currently PRs to it do not go to the maintainers, but I think it would greatly simplify the path of user contributions if GitHub PRs were auto-submitted using the proper Postgres process (i.e. with a bot?). Just compare the above 2 clicks process to submit a documentation change with the giant instruction page at https://wiki.postgresql.org/wiki/Submitting_a_Patch -- clearly it is a big deterrent for small improvements.
On Mon, May 4, 2020 at 3:23 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> On 4 May 2020, at 19:06, Magnus Hagander <magnus@hagander.net> wrote:
> Question is if the benefit would outweigh the cost, compared to just receiving
> comments and "manually patching them in".
Another question is the cost of managing access to such a system, we haven't
exactly had the best of luck with input from interactive systems in the past.
Is a community login enough or does it need an extra bit like the Wiki? Just
thinking out loud of the costs involved which need to be offset.
cheers ./daniel
(accidentally sent my last post without the links at the bottom, fixed)
* While viewing the "CREATE TABLE" page [1], I click some "edit" button (e.g. in the upper right corner)
* It takes me to the GitHub "edit" page [2] (this is the link target of the gray pencil icon on page [3] - upper right corner on gray background)
* I edit the page -- the syntax seems trivial enough for the vast majority of non-structural edits. I can add more examples, improve grammar, add links, etc.
* I click "Propose file changes" at the bottom. This automatically will create a fork of the repo, and create a pull request into the main Postgres github repo.
* (automated step) some bot creates a PR against the primary Postgres repo, submitting the change.
* Maintainers review and merge the change.
Now, I do see that https://github.com/postgres/postgres is not the primary repo, and that currently PRs to it do not go to the maintainers, but I think it would greatly simplify the path of user contributions if GitHub PRs were auto-submitted using the proper Postgres process (i.e. with a bot?). Just compare the above 2 clicks process to submit a documentation change with the giant instruction page at https://wiki.postgresql.org/wiki/Submitting_a_Patch -- clearly it is a big deterrent for small improvements.
On Mon, May 4, 2020 at 3:23 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> On 4 May 2020, at 19:06, Magnus Hagander <magnus@hagander.net> wrote:
> Question is if the benefit would outweigh the cost, compared to just receiving
> comments and "manually patching them in".
Another question is the cost of managing access to such a system, we haven't
exactly had the best of luck with input from interactive systems in the past.
Is a community login enough or does it need an extra bit like the Wiki? Just
thinking out loud of the costs involved which need to be offset.
cheers ./daniel
On Mon, May 4, 2020 at 07:06:55PM +0200, Magnus Hagander wrote: > I see how that can be pretty useful for something that's as simple as asciidoc. > But I wonder how useful it would be for our docbook documentation. > > There'd be no preview (which there i sin the elastic), and we know how > difficult it can be to get the tags right without running test builds even for > those that are used to working in the system. > > Though if what we're considering are basically drive-by typo fixes and such, > those would probably work in a scenario like that, since you're unlikely to > need a preview or break a build. > > Another complication would be that we don't have a 1-1 mapping between source > files and output URLs. So you'd have to find some way to track it back to the > exactly right portion of the source file. This would probably be possible if we > were to do it as a feature on our own site (and not just a > source-edit-on-github-style), but it would probably ont be a trivial piece of > work. Question is if the benefit would outweigh the cost, compared to just > receiving comments and "manually patching them in". All I can say is that most emails we get about the docs using the form are just complaints, and we have to write some suggested text and get approaval from the reporter that the text is clear. We don't get many acutal _suggestions_. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Tue, May 5, 2020 at 4:49 PM Bruce Momjian <bruce@momjian.us> wrote:
On Mon, May 4, 2020 at 07:06:55PM +0200, Magnus Hagander wrote:
> I see how that can be pretty useful for something that's as simple as asciidoc.
> But I wonder how useful it would be for our docbook documentation.
>
> There'd be no preview (which there i sin the elastic), and we know how
> difficult it can be to get the tags right without running test builds even for
> those that are used to working in the system.
>
> Though if what we're considering are basically drive-by typo fixes and such,
> those would probably work in a scenario like that, since you're unlikely to
> need a preview or break a build.
>
> Another complication would be that we don't have a 1-1 mapping between source
> files and output URLs. So you'd have to find some way to track it back to the
> exactly right portion of the source file. This would probably be possible if we
> were to do it as a feature on our own site (and not just a
> source-edit-on-github-style), but it would probably ont be a trivial piece of
> work. Question is if the benefit would outweigh the cost, compared to just
> receiving comments and "manually patching them in".
All I can say is that most emails we get about the docs using the form
are just complaints, and we have to write some suggested text and get
approaval from the reporter that the text is clear. We don't get many
acutal _suggestions_.
Agreed. I think the argument made is that if we had direct editing, maybe we'd get more actual suggestions vs just reports/complaints.