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.