Ok, cool... I got 3 answers so far, all 3 answers were one-liners... it
seems I made people relax a little... lol, damn I hate looong useless
discussions (but do love looonnnggg emails, hopefeully useful)
by the way, those one-liners meant "we're ok with everything you said"
or
did they mean "I didn't get anything from what you said, was it even
english?", hehe...
ok, so here's the teams assignations so far... please answer directly by
modifying this list :
* aMSN Team (amsn1).............(everyone)
* aMSN2 Team (amsn2)
*RnD
- libmsn team ....................(Youness, GrdScarabe)
- D-bus for Tcl team .............(Karol)
- telepathy to GUI layer team ....(?)
- XML2GUI team ...................(Youness, Vivia)
- GUI team .......................(Tom, Lee)
* Web/Documentation.......(Lee, Diego, Yves)
* QA..............................(Alberto, Thomas)
* Management (+design)................(Youness, Burger, Harry)
KaKaRoTo
On Tue, 13 Dec 2005 12:56:48 -0500, Alberto Diaz
<[EMAIL PROTECTED]>
wrote:
> I volunteer for Q&A so, contact me if u want.
>
> Alberto
>
> El Tuesday, 13 de December de 2005 05:57, Youness Alaoui escribió:
>> ok, ok everyone, relax... I already said in a previous email that I
had
>> a
>> plan to organize all this and that it would be (partially) based on
the
>> system we use at my job.. with the difference that it would take into
>> consideration that it is no professional product and we do this in
our
>> free time...
>> My idea is to have three more teams actually :
>> 1 - general administration
>> 2 - QA (Quality of Assurance.. basically testers with professional
>> behavior and tasks)
>> 3 - Documentation
>>
>> + a global 'RnD' team, which would consist of the teams listed
below...
>>
>> I would like to set up a system for the work to be done, once a
design
>> is
>> comleted we'll have hunderds of tasks, and I'll probably create a
sample
>> code for everyone to start with (the interface of each class at
least as
>> well as documented API within the code) now.. you have a simple task
>> like
>> "enter code for this functionality".. with detailed discussion on
it, so
>> we can keep track of everything said on it (no copy paste of emails,
>> someone in charge of this would enter a few lines to summarize the
>> important points).. you would do it, and send an email to a mailing
list
>> saying "completed task XXX" with the number of the task... we'll use
>> trac
>> for this kind of job... we will also use SF.net's 'tasks' system...
>> we'll
>> see all that in time...
>> now, here's the thing.. you implement a feature, so you send an
email to
>> say 'I finished this', EACH commit, should have the 'ticket number'
>> which
>> means you are NOT ALLOWED to commit anything if it's not already
entered
>> in the system as a ticket... so if you want a new feature, you would
>> send
>> a mail to the admin (me) with an explanation of what you want and ask
>> for
>> a new ticket to be created.. once it's accepted and created, I'll
send a
>> mail telling you "here's your ticket", then you have the right to add
>> your
>> feature and commit your change with the ticket number in the
comments of
>> the commit...
>> Each commit that would create a new feature OR have a feature change
>> (new
>> command line option, new API function, build number changed which
makes
>> our internal config file incompatible with a new version (from
key/value
>> pairs to XML for config.xml for example)) you would have to CC the
doc
>> manager in your 'completed' email..
>> I will send templates for these kind of files... so something like :
>> =========================================================
>> Ticket : 1043975 - Request to have a command line option for
whatever...
>> Fix date : octeber 10th 2010
>> Fixed by : Kakaroto
>> Fix information : PARTIALLY FIXED || FIXED
>>
>> To complete the feature request, I added a new option -d to be able
to
>> do
>> this...
>> note that if the -d option is supplied, it will override the -c
>> option...
>>
>> What to test : command line options with -d and -c, permutations, and
>> other options, and this ... behavior when having/not having the
option
>> enabled in the command line...
>> =========================================================
>>
>>
>> ok, so that's an example.. this email would go to a mailing list
with a
>> CC
>> to the QA manager and the doc manager and myself (and the requester
of
>> the
>> feature if any)... a copy should be pasted in the ticket information
on
>> trac, and the ticket set to "needs to be tested"... the doc manager
>> would
>> automatically update his documentation based on this and the QA
manager
>> would automatically test it, make sure it introduced no side effect
>> bugs,
>> and then close the ticket if it's perfect...
>>
>> this will assure us that the docs are always up to date, that
everything
>> is documented in the meaning that you are to fix a bug, and you see
>> "humm.. to fix the bug I have to remove this bit of code, but that
code
>> is
>> there specifically to do something, why was it added in the first
place
>> ???", you look at CVS history, you get the commit, if you don't have
>> enough info from the commit log, you can see the ticket number, go to
>> trac, search for the ticket, and see detailed info about the
bug/feature
>> that was requested, also, about who fixed it, who asked for it, when
was
>> it done, etc...
>>
>> This is what I meant by we need people to be serious, because I don't
>> want
>> to send an email to someone in docs and never get a reply after a
month
>> or
>> two... and never see a change... we need people to be ORGANISED!
which
>> mean an email client where incoming mail would go to a certain dir,
when
>> you finish something, you move the mail to a 'done' dir, you tag
emails
>> as
>> 'TODO' and have a followup directory, and if after a week you didn't
get
>> the chance to document something in your followup dir, answer the
poster
>> and say 'hey, I got your mail, don't worry, it's not lost somewhere,
>> I'm a
>> bit busy, I'll take care of it when I can, but don't worry, it's in
my
>> followup directory'.. so we're not like 'when is the work gonna be
done
>> ???'
>>
>> Anyways, this is my fast explanation of a model at almost 1AM and I'm
>> completly exhausted... so please, just stop talking about this..
we're
>> not
>> yet into programming, not yet into documenting.. for the moment
we're in
>> designing the teams, then we'll be designing the structure, then
choose
>> a
>> language, then design the tasks, then divide and assign the tasks,
then
>> start coding, then the documentation comes after that, then the
>> testing...
>>
>> This model can be very loose, it can be modified to fit everyone's
>> needs,
>> it will be discussed long enough so everyone can get a
>> working/efficient/trouble-free system to have a great project... so
>> please
>> don't panic and say "ahhh, I don't want to write emails" or "ahhhh, I
>> want
>> to add whatever feature I wantttt"... we'll see that in time, for
now...
>>
>> honestly, now I don't know what I was talking about, I'm really
tired..
>> so
>> really, sorry, but I'll leave it as it is..
>> my main point was "stop worrying about irelevant things for now...
and
>> concentrate on what really matters"..
>>
>> >> * aMSN Team (amsn1 ?).............(everyone)
>> >> * aMSN2 Team (amsn2)
>> >> - libmsn team ....................(Youness, GrdScarabe)
>> >> - D-bus for Tcl team .............(Karol)
>> >> - telepathy to GUI layer team ....(?)
>> >> - XML2GUI team ...................(Youness)
>> >> - GUI team .......................(Tom, Lee)
>> >> - Web/Documentation.......(Lee, Diego, Yves)
>> >> - QA..............................(?)
>>
>> I will need someone to help me for the XML2GUI project, I think Phil
on
>> the libmsn team (confirm please) and someone for the layer between
>> telepathy and the GUI... Karol, you think you'll need help ? Tom,
Lee,
>> good luck, I think you're on the right track already... web/doc,
>> perfect,
>> we'll assign managers of each team later... QA who wants to ?
>>
>> ohh.. there were some questions from scarabe too :
>> > The questions are :
>> > - Do these groups correspond to the work we have to do ?
>>
>> yes, of course, what do you mean ?
>>
>> > - Who are the responsibles/leaders of each group ?
>>
>> we'll see, we don't even know who's in the groups... but basically,
I'll
>> be the manager of everything, I can be manager of all groups + of all
>> individual group
>>
>> > - How do they refer with each others ?
>>
>> what do you mean ? they will be individual projects.. the only thing
>> that
>> needs to understand the other projects is the telepathy2GUI layer,
which
>> will be easy to do as long as the public interfaces that we define in
>> the
>> design phase NEVER change...
>>
>> > - What are the artifacts that will preserve us from interfacing
>> > problems ?
>>
>> what do you mean ?
>>
>> > - How will every team refer to the global leader (Youness ?)
>>
>> also what do you mean ? refer to ? there are emails... hehe, I didn't
>> get
>> your question
>>
>> > - How will documentations/specifications live together ?
>>
>> I think I just explained it
>>
>> > - Do we create a new list to preserver each branch from the
>>
>> development
>>
>> > of the other (this list is quite missy now ) ?
>>
>> yes of course, a new list... a new list for all discussions, maybe a
>> list
>> for each individual project + one for all projects + one for specific
>> tasks (like for documentation-TODO and for 'ticket-completed',etc...)
>> everyone should be subscribed so this way we all get the same
messages,
>> but we would have the messages filtered in an easy way (and we may
have
>> a
>> bot listening to some lists, like the doc and which would organise
>> things... like a 'add-to-wiki' mailing list which would have a bot
>> subscribed and which would add to the wiki directly and answer you
with
>> a
>> link, you would only have to link to the page from wherever you want)
>>
>> > - How insuring code quality/clarity in the new branch ? (cvs
masters
>>
>> ?)
>>
>> I never understand your questions!!!
>>
>> and lastly, about chat logs, no, it's not automatic, it's not stored
>> anywhere either.. it's actually the log of the bot, which can be
>> transformed into an html log file using a script (reads the bot-log
file
>> and create a chat-log file).. I would need a cron job to do it, and
>> basically a script that would make sure the file is in .gz format
(which
>> means the log file is completed) and wasn't already extracted (logs
are
>> stored per day 20051210.gz 20051211.gz, etc... and you do a
>> ./createchatlog 20051210 for example)... once I have that and create
a
>> cron job, we'll be able to have per-day chat logs...
>>
>>
>> KaKaRoTo
>>
>> On Mon, 12 Dec 2005 23:21:32 -0500, Lee Olson <[EMAIL PROTECTED]>
>>
>> wrote:
>> > On 12/12/05, GrdScarabe <[EMAIL PROTECTED]> wrote:
>> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> Hash: SHA1
>> >>
>> >> >>Personnally I'd like to work on libmsn with Youness if everybody
>> >>
>> >> agree ...
>> >>
>> >> * aMSN Team (amsn1 ?).............(everyone)
>> >> * aMSN2 Team (amsn2)
>> >> - libmsn team ...................(Youness, GrdScarabe)
>> >> - D-bus for Tcl team .............(Karol)
>> >> - telepathy to GUI layer team ....(?)
>> >> - XML2GUI team ...................(Youness)
>> >> - GUI team .......................(Tom, Lee)
>> >> - Web/Documentation.......(Lee, Diego, Yves)
>> >>
>> >> >>Do we continue working on the list ... I'm not against the IRC
but
>> >> >>
>> >> >> - there is no historic of what is said
>> >> >
>> >> > I think Youness is logging it all with his bot.
>> >>
>> >> That's cool ! Are the logs published somewhere ?
>> >>
>> >> I'm ok to work on documentation too if needed ...
>> >>
>> >> What do you think, instead of a team "documentation" to have a
>> >> responsible for documentation/relations in each team ?
>> >>
>> >> It will be easier for someone involved in the coding to document a
>>
>> part
>>
>> >> that someone totally out of the development !
>> >>
>> >> I'm also thinking to litterate coding ... but I don't know how
all of
>> >> you consider this method ...
>> >
>> > I would appreciate your help in documentation. Once I have more
time
>> > to get things organized, I would like to start assigning
documentation
>> > tasks, but until then, we need to clean up what we currently have
on
>> > the wiki and other places.
>> >
>> > Developers will need to consult with a documentation manager so
that
>> > we can merge documentation from the developer when they are adding
>> > something new to aMSN, or documenting something technical that a
>> > documentation member would not necessarily be able to explain
quite as
>> > well. I like the idea of having documentation relations with each
>> > team, but we must also think of how the documentation will all come
>> > together as a whole.
>> >
>> > I suppose each documentation relation from each team would combine
the
>> > documentation which they receive and give it to the head
documentation
>> > manager, who would organize everything and make sure it's
presented in
>> > a clear, readable, and standard way.
>> >
>> > We must also consider how the wiki is maintained. Maybe we need to
>> > establish a maintainer for that just to make sure that things are
>> > being kept organized and up to date.
>> >
>> > ~Lee
>> >
>> >> GrdScarabe
>> >> -----BEGIN PGP SIGNATURE-----
>> >> Version: GnuPG v1.4.2 (GNU/Linux)
>> >> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>> >>
>> >> iD8DBQFDnkTbPmfsnt4Id3wRAtDCAJ9K+UlmXmybnQfsurbSJmr4sy1p3QCfWJv+
>> >> /oGwEn5x6nu7n/o8nbehdcY=
>> >> =lK8P
>> >> -----END PGP SIGNATURE-----
>> >>
>> >>
>> >> -------------------------------------------------------
>> >> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>>
>> log
>>
>> >> files
>> >> for problems? Stop! Download the new AJAX search engine that
makes
>> >> searching your log files as easy as surfing the web. DOWNLOAD
>>
>> SPLUNK!
>>
>> >> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> >> _______________________________________________
>> >> Amsn-devel mailing list
>> >> Amsn-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>> >
>> > -------------------------------------------------------
>> > This SF.net email is sponsored by: Splunk Inc. Do you grep through
log
>> > files
>> > for problems? Stop! Download the new AJAX search engine that
makes
>> > searching your log files as easy as surfing the web. DOWNLOAD
>>
>> SPLUNK!
>>
>> > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>> > _______________________________________________
>> > Amsn-devel mailing list
>> > Amsn-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel