Get final merges in to Ubuntu Docs

[Matthew East]

On 13 September 2013 17:50, Benjamin Kerensa <bkerensa at ubuntu.com> wrote:
> So I spoke with Lyz this morning she agrees with you and Doug but I still
> think its a risk. The stats you shared likely reflect commits that had
> already been peer review in Gnome of which Jeremy was also a contributor so
> peer review downstream for merging from upstream did not make as much sense
> in those cases.

In terms of the team's historical policies, that's not correct. As far
back as I can remember there hasn't been any policy of mandatory peer
review for members of the ~ubuntu-core-doc team. The process has been
that patches and merge proposals from non team members have been
subject to review by a ~ubuntu-core-doc team member before being
applied to the branch, but that membership of the ~ubuntu-core-doc
team conferred the ability to push directly to the branches, without
necessity for peer review. The whole point was that inclusion in that
team was given to people who had demonstrated the necessary attention
to detail and level of understanding that they can be trusted to push
directly. This followed the model in Ubuntu development, whereby
members of ~ubuntu-core-dev could push changes to any packages
directly to the repository during the development cycle. (From what
Stephen Webb has said in this thread, it could be that this has
changed in recent times, I don't know as I haven't followed Ubuntu
development for a while.)

Very occasionally if someone was uncertain about a commit, or thought
wider consultation on a particular change was appropriate, they have
asked for feedback on the patch, but that did not reflect a general
policy.

This is purely to explain the history, since it has come up. That's
not to say that the team should or shouldn't follow that process in
the future, obviously it can impose whatever process it feels
appropriate. For what it's worth, my opinion is that Doug and Kevin
have certainly demonstrated all the attributes and more that past
members of ~ubuntu-core-doc have had and I agree that where time is
short, updated documentation with possible minor inaccuracies is
vastly preferable to misleading and outdated documentation.

Matt