[TYPO3-core] Patches requiring documentation

[Xavier Perseguers]

Hi,

> 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