[TYPO3-content-rendering] RFC: Improving content-rendering -- core - Workflow

[Ernesto Baschny [cron IT]]

Sebastian Kurfuerst schrieb am 17.04.2006 14:02:

> this is the right place to discuss how to make the workflow between the
> content-rendering group and the core group more effective.
> As always, any comments are welcome. My suggestions follow now:
> 
> I think it makes sense if you (=the CRG people) fix the CRG issues, as
> you are experts in this area, the core team might not be.
> For further discussion of open issues, I suggest we create a new BT
> category, named "Content Rendering"... Or, do you think it makes sense
> to use the CSS styled content category for it, maybe even rename it?

I think a new category makes sense, as there are content issues that are
not strictly css_styled_content related, for example the IMGTEXT
problems. Its difficult to find those, if they are mixed with other core
related problems.

> We should have a "Review team" inside the CRG as well, consisting of
> maybe 4 people: 2 programmers, and 2 others who test the output. Of
> course this could be changed, but as Content Rendering is so important,
> we definitely have to look at backwards compatibility and upgrade paths.
> I think these reviewers can get the "updater" role in the bugtracker.
> 
> Then, wenn a bug arrives (whoever reports them), everybody can post a
> fix, and the CRG review team can review it then. When everything is
> approved, a core team member (for example myself, Rupert, whoever) can
> take care of getting it into the core.

I agree with this workflow.

> I suggest a following structure for the core information: (Which can be
> pasted directly into the core list!)
>  - Problem Description
>  - Solution
>  - possible side-effects
>  - backwards-compatibility
>  - changes in rendering?
>  - Who has approved the patch, being the responsible person for it?
> (That person is contacted then when there are problems => I'd suggest
> the reviewers).

I suggest that the group itself (this list) is the "contact person".
People from our group sometimes come and go. If everything is done in
public we (in the group) can easily find the responsible person(s) and
know if they are still active or "missing in action" and find a new way
of handling the case.

> Please tell me what you think, and what you are willing to do, then I
> could set up the necessary things in the bugtracker.

In the past couple of weeks I have handled all bugs that have been
reported in the "css_styled_content" project in the bug tracker and I
could continue doing that. I don't expect that many bug reports through
the bug tracker on content rendering issues (except some about the new
IMGTEXT rendering), because most people just expect the output to be
correct and don't bother to check. And those who bother are in our group
anyway and start the discussions here. So I think most new stuff will
still be generated through this list and through our group.

But for consistency I would like to keep using the bug tracker to track
new features, as its easier to reference later (bug id#), to attach
patches and to communicate with other core members. So I think the
programmers (me.. others?) and the reviewers (ben, JoH, others?) should
have "updater" roles in this project in the bug tracker.

Cheers,
Ernesto