* 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
