Re: Merge Request workflow for docs updates (was Re: RFC: Merge Request documenting a contributor-initiated orphaning process in the Developers Reference)

* Jonathan Dowland <[email protected]> [260701 10:40]:
>(This was motivated by Andreas's mail in <[email protected]> 
>but is not directly related to that piece of work.)
>
>What are my fellow developer's opinions on the suitability of the 
>Merge Request workflow for documentation updates?
>
>I like the idea in theory, but my experiences so far (most recently 
>with Raphael's DEP improvement work) is that it very quickly breaks 
>down. For software, quite often the feedback you receive on a PR can 
>be resolved in a very local manner: i.e., you can fix a typo, add a 
>comment, adjust the approach used within a function, and the result is 
>a very localised change, and this works fine with MR feedback.
> [..]

I don't think it's very different.

For software and documentation/policies/texts, both, IME:
if the general direction is already clear, then a merge request 
works for review.

If the general direction is not clear, a merge request is a horrible 
way of agreeing on the general direction, and usually a waste of 
resources.

Try thinking it through: if you get an MR for a software project and 
your reaction is "ok nice, but thats not at all something I want 
this software to do" - then the typical MR/PR tooling does not help 
at all. And it's typically terrible UX to express a different idea 
in it.

Best,
Chris