Hi,
to go a step further: Do we need such feature mails at all? Couldn't we
instead offer RSS feeds (per project?) which list the most recently
integrated CWSs and their feature descriptions?
I could imagine that a developer can edit the feature description at any
time he likes and, at the
Hi Jörg,
to go a step further: Do we need such feature mails at all? Couldn't we
instead offer RSS feeds (per project?) which list the most recently
integrated CWSs and their feature descriptions?
It's a matter of taste and/or working habit whether you want to read a
Feed or a mailing list.
Hi Bernd,
On Thursday, 2006-11-16 16:08:34 +0100, Bernd Eilers wrote:
The questions where I am currently unsure about are the following:
1.) can automatically move all featuremails/api-changes from state draft
to state finished when the state of the CWS moves to state 'ready for
QA' or
Hi Frank,
On Wednesday, 2006-11-15 13:43:22 +0100, Frank Schönheit wrote:
I'd prefer an ability to add feature mails in EIS which are not yet
sent. That is, I would like to fill out the form for the feature mail,
and press some Send Later button. The mail would then be associated
with the
Hi Matthias!
Mathias Bauer wrote:
(1) While developing your feature: discuss feature with people on IRC,
mailing lists and whatsoever to your liking; it is *recommended* (though
not mandatory) to contact the project lead as early as possible and
discuss with QA and UserEx also (not to ask for
Mathias Bauer [EMAIL PROTECTED] writes:
step1 - idea: mandatory ;-)
step2 - create iTeam: optional at this point in time as we can't expect
it for all community work
step3 - design/review/implementation cycles: indispensable :-)
step4 - create iTeam if not done in step2: possible to be done
Michael Meeks wrote:
Hi Mathias,
On Tue, 2006-11-07 at 19:40 +0100, Mathias Bauer wrote:
I don't see our discussion related to the way something is implemented,
so this splitting IMHO is an implicit one. So my idea was (and still is):
So - the problem is I discern ~no difference at
Hi Mathias,
Mathias Bauer wrote:
Possibly we can establish a process that allows for more asynchronous
work or creates the documentation in a QA style (QA or documentation
ask for the information they need instead of forcing the developers to
provide everything upfront).
As some of us have
Joerg Sievers wrote:
Hi Mathias,
Mathias Bauer wrote:
Possibly we can establish a process that allows for more asynchronous
work or creates the documentation in a QA style (QA or documentation
ask for the information they need instead of forcing the developers to
provide everything
Michael Meeks wrote:
Nope, seems a good summary; one of the ideas I came up with was of
splitting the work-flow aspects [ step1: create iTeam, step2: design,
step 3: review, step 4: implement ] etc. from the other pieces that are
necessary for QA / docs / i18n etc. ie. providing
Hi Mathias,
Sorry - didn't notice your summary before posting mine. OTOH - yours
looks rather better than mine, thanks so much for taking the time here.
OTOH - I make some more concrete proposals, so perhaps there is some
value in discussing both in the same thread.
It really
Hi together,
as I have the feeling that many discussions in our most beloved thread
started to go around in circles I want to break out and focus the
discussion by providing a personal summary of it. Please read this
summary as a whole before you comment on single items, I really tried to
cover
12 matches
Mail list logo
