[TYPO3-typo3org] TYPO3.org team - organisation / processes

Robert Lemke robert at typo3.org
Tue Apr 4 09:50:33 CEST 2006


Hi folks,

as mentioned in the "Useless extension inflation" thread, I'd like to
discuss the general organisation of the TYPO3.org team. Sorry, it's a long
mail - I didn't know that I can write that much at once ...

Recently I have invested a few hours into restructuring the TYPO3.org team
pages [1]. My intention is to find out, how a team section can be
structured and use the result as a template for other team sections at
TYPO3.org.

The problem with the existing pages were:

  - visitors of TYPO3.org had problems finding the right contact for their
    question or suggestion
 -  the team was just a collection of a few team members without proper
    job descriptions - everything had somehow to do with TYPO3.org, but
    you didn't really know what who was doing
 - collaboration within the team is difficult, mainly because no workflow 
   was defined and place for storing information didn't exist

So I thought about how our team should be structured in general:

  TYPO3 Association
    \ 
     R&D committee
       \
        TYPO3.org team
          \
          Hosting working group
          Templates & Design working group
          Coding & Extensions working group
          Content working group

Each TYPO3.org team member is member of one or more working groups which are
specialized on specific tasks within the team. Each working group has it's
own "homepage" and list of contacts and can have one ore more projects.

If you look at the pages of the Hosting working group [2], you see that even
that group has different tasks to deal with. My hope is that by structuring
it this way, the tasks and people involved are more transparent for those
who are seeking for the proper contact. 

Back to a specific problem, basically the reason why I started making the
new structure and started this thread:

Behind the scenes, there are several extensions which create the output on
TYPO3.org. Two prominent examples are the ter_fe and the ter_doc extension.
Now we have the situation that other developers want to contribute and help
fixing bugs, implementing new features. Michael Scharkow, for example, sent
a patch for a modified frontend output of the extension lists.

The situation seems to be quite simple: I install the patch, see what
happens and if it works I install the modified extension at TYPO3.org. But
this way of doing it has several disadvantages, as I'd like to point out
and discuss with you.

Let's see what this paticular contribution consists of:

  - First thing is the modified PHP code. That code has to be reviewed and
    we have to agree on a common coding style.

  - Then we have HTML / CSS output. It has to be checked if the FE output
    matches the overall design at TYPO3.org and if the HTML / CSS is 
    technically okay

  - Before we code anything, we should have at least a common goal or
    a general concept for important elements of TYPO3.org. Without that
    we just develop small parts when we need them and because we don't
    see the big picture, we soon have a patchwork of extensions which don't
    fit together.

My proposal for this specific situation is this:

  - The TYPO3.org team as a whole creates an initial (no matter how short)
    concept for the further development of TYPO3.org. In fact I already have
    a little brainstorming running with Martin Herr and we should discuss
    details after 4.0 is out and we have taken a deep breath ...

  - We form a Coding & Extensions working group. That's the place were
    Michael and I are working together. In the long run we must make sure
    that a few members of this group are authorized and have enough 
    information to deploy extensions and other code at TYPO3.org themselves.
    We need a reviewing process, eg. like in the core team and we need to 
    document important tasks and create checklists.

  - We form a Templates & Design working group. I imagine that members of
    the Content Rendering Group [3] and the Design Team [4] form this new
    group. Before the Coding & Extensions group installs an extension which
    contains not only minor changes in its frontend output, they install the
    extension in a testing enviroment and ask the T&D group to check the 
    design and HTML / CSS code.

I would like to distribute and fix responsibilities. Generally, the C&E
group is responsible for all PHP code used on any official TYPO3 website.
If in doubt, the group leader has the last word on decisions. The same goes
for the design: The Design Team [4] and it's team leader has the last word
on any design decisions. For our convenience, we have our own sub group of
the Design Team within the TYPO3.org team.

In my opinion we can only achieve a steady quality for code, design, content
etc. if we define these responsibilities and respect them. See, I'm no
designer and I'm really happy with the overall branding process including
our new CD. And even though I personally might like to change certain
things, I don't do so right away. For me a consistent design is more
important than accepting everyone's suggestions.

Well, I guess you see now what I've been thinking about. Let me now make a
proposal for the next steps ...

- Please give general feedback on these ideas, just post them within this
  thread

- Form the working groups. We should open a thread for each working group[5]
  and discuss the next steps and further details. If you'd like to work in 
  such a group, join the thread and let us know your vision and what you
  would like to contribute.

- Within the working group threads: Discuss workflows and the overall 
  process. Create a wiki page for it, collect and refine the ideas. In the
  end we should be able to create a page for each group which contains
  the most typical tasks and how to work on them.

Just to give a few examples for the in-working-group-discussions (not too
many, I really have to end this mail ;-) ... there are many many questions
we have to find an answer for:

  - how can we work on the HTML / CSS and TypoScript templates together
    and easily (and safely) install them on all official TYPO3 sites? CVS? 
    SVN? File based TypoScript templates?

  - we need testing enviroments - copies of TYPO3.org. Who creates and
    maintains these? How can we update them regularly so they reflect the
    real state at the live TYPO3.org site? What confidential data has to be
    removed for the clone?

   ...

Okay, thanks a lot for reading until here. I'm curious what you think about
it!

robert


[1] http://typo3.org/teams/typo3org/
[2] http://typo3.org/teams/typo3org/teams/hosting/
[3] http://typo3.org/teams/content-rendering/news/
[4] http://typo3.org/teams/design/
[5] http://typo3.org/teams/typo3org/working-groups/

-- 
Robert Lemke
TYPO3 Association - Research & Development
Member of the board
http://association.typo3.org




More information about the TYPO3-team-typo3org mailing list