As team leader of the german development team I found it very handy that have a status for the translation members. Which part has to be translated, which was already proof-read, to have a list of members, who is working on what and so on.

Now that we have 100% translated for german I don't need it anymore, but I think other language leads could find it very handy.
The manual status page is sometimes not enough information.

My 2 cents.

Thomas
I18N and German Team Lead


----- Original Message ----- From: "Wil Sinclair" <[EMAIL PROTECTED]>
To: "Simone Carletti" <[EMAIL PROTECTED]>
Cc: <fw-general@lists.zend.com>
Sent: Monday, December 17, 2007 8:52 PM
Subject: RE: [fw-general] Project Teams and Separate Mailing Lists. . .


That seems reasonable to me. I don't see any issue with maintaining
translation pages in development, but we should make sure we aren't
setting ourselves up for getting immediately out of date. As far as I
can tell, the areas that go out of date very quickly include the current
status of the project, names of people working on the project, etc. And
even these wouldn't be an issue if there is a lead maintaining the page,
as with the Italian and French pages.

So how about this? We can create a standard header for each translation
so that all the information that is the same across the translations
will appear in the same place, and custom content can go beneath. If no
translation lead wants to take ownership of the page, the page will only
contain that header, which would include stuff like the language name, a
link to the docs on the wiki, and maybe a note that this translation is
available for someone to actively lead. All of these pages can go under
a new 'translations' page under the documentation guide
(http://framework.zend.com/wiki/display/ZFDEV/Zend+Framework+Documentati
on+Guide). If we find that a translation page has gotten out of date, we
can archive the custom content and leave the header.

Do you find the concept of a 'translation team' useful? If so, what does
it bring us? The other project team pages seemed to bring little value
and mostly served to list the names of people who said they would help,
but were busy when it came to the actual 'helping' part. J



,Wil



From: Simone Carletti [mailto:[EMAIL PROTECTED]
Sent: Monday, December 17, 2007 10:49 AM
To: Wil Sinclair
Cc: fw-general@lists.zend.com
Subject: Re: [fw-general] Project Teams and Separate Mailing Lists. . .



Because translation activity is strictly part of Zend Framework
development and improvements, and follows an internal workflow,
including an SVN powered storage, I would suggest to think about a
translation section under development area.

Additionally, I remember I didn't provide much credit to User Space
section when I first came across ZF framework, many months ago. I jumped
directly to development section.
I had a look to user area just a few weeks later, when I started to get
involved into ZF development.

This is why I think the translation section could find a better place
under the development area.
If you feel more comfortable it is possible to start with a small set of
pages to reduce the number of outdated pages, including howto guidelines
and other helpful information.
Then each single user (translator) could decide to use custom pages
under user area depending on custom needs.

What do you think?

-- Simone



On Dec 17, 2007 7:33 PM, Wil Sinclair < [EMAIL PROTECTED]> wrote:

Well, I would call it more of a 'update' than a 'reorganization'. The
development space had a bunch of outdated content on it that was
generally misleading and gave the wiki a somewhat abandoned feel. While
the user space can be more freeform, the development space we use for
lots of structured, important content that we'd like to keep as clear
and concise as possible. The page you mention happens to be under
project teams, which are going away as a concept, although I don't want
to take away any tools that are useful for anyone. Would you prefer a
new translation section of the development space, or would you rather
have the freedom of the user space to do pretty much whatever you want
with it?

,Wil

Talking about project teams and wiki... I saw you just moved the most
part
of pages under /archive group that is write protected.
It means, for instance, we cannot edit any team or translation page,
such as
http://framework.zend.com/wiki/display/ARCHIVE/Italian+%28Italiano%29

Is there any wiki reorganization in action?

-- Simone


wllm wrote:
>
> Does anybody find the concept of project teams (as laid out here:
> http://framework.zend.com/wiki/display/ZFDEV/Project+Teams)
worthwhile?
> That is to say, not just occasionally useful, but actually worth the

> extra effort to maintain and the additional complexity that they add
to
> the overall project? Most of the project team pages on the wiki are
> woefully out of date at this point, and I happen to be very
skeptical
> about any process or structure that isn't part of any critical
workflow
> for a project- they tend to get abandoned as soon as higher-priority
and
> more immediate tasks come up- as these seem to have been.
> Also- separate mailing lists- same question. Only 3 lists get more
than
> the occasional mail: general, mvc, and db. I'd venture to guess that
> most of us subscribe to all 3 of these, and people tend to
cross-post
or
> post specific questions in general if they want to make sure
everyone
> reads them anyways. Our traffic across all mailing lists adds up to
> about 5-10 mails per day, which IMO is a nice lively- but not
> overwhelming- mail rate on a list. If you think that some of these
> separate lists are useful, why and which ones? Please keep in mind
the
> potential confusion of those new to framework who have a question
and
> may not know which place is best to post it or that some of these
lists
> are not widely read.
>
> Thanks for any feedback.
> ,Wil
>
>

--
View this message in context: http://www.nabble.com/Project-Teams-and-
Separate-Mailing-Lists.-.-.-tp14360219s16154p14370312.html
Sent from the Zend Framework mailing list archive at Nabble.com.




Reply via email to