[TYPO3-core] Patches requiring documentation

Xavier Perseguers xavier at typo3.org
Mon Oct 14 14:49:27 CEST 2013


> So the issue should be opened during the review phase already? What
> happens if the change is not merged at the end? Should the documentation
> issue state "this is being reviewed currently" or how will you
> differenciate issues that "need to be documented" from the "not yet
> merged, this is just a placeholder"?

It may simply "follow" the Core patch.

> Forgive me if this has been discussed (maybe even "over and over"), just
> curious about the argument (because I thought we had agreed otherwise
> before): Wouldn't it be more efficient to only document what was merged
> at the end? So that the commit message cannot contain a "Documentation:
> #..." line, but *on merge* the issue *has to be created*?

This works if people do the merge and think carefully about everything
but I fear the risk is really high that it will be forgotten.

Although, having a ticket describing a bit what should be documented,
and where to put the info is already a big part of the documentation
job. As stated by Francois, the doc team does not wait for
ready-to-commit documentation patches (although it would be even better
of course) but having at least a rough description in the ticket that
just needs to be rephrased, possibly already with 1-2 screenshots if it
makes sense makes the doc-team work so much a pleasure.

Furthermore, doing that by the merger is too much work, this is the
reason I would tend to be the same opinion than Francois and ask the new
feature, or change to be "documented" right away!

Kind regards

Xavier Perseguers
Release Manager TYPO3 4.6

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org

More information about the TYPO3-team-core mailing list