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
