[Pharo-project] How to manage todo?
Hi guys We have bug entries and now I have one question. Do we want to mix or not todo within them? I deleted all the old tasks from the inria web site. Now we could use it. Do you have experience managing todo (which may be orthogonal to issue and bug trcking)? Stef
I propose that we use Type-Task or Type-ToDo for the management of some items that are not directly bug. Marcus? adrian? is it ok for you? Stef On Apr 7, 2010, at 3:38 PM, Stéphane Ducasse wrote:
Hi guys
We have bug entries and now I have one question. Do we want to mix or not todo within them? I deleted all the old tasks from the inria web site. Now we could use it.
Do you have experience managing todo (which may be orthogonal to issue and bug trcking)?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Apr 7, 2010, at 3:50 PM, Stéphane Ducasse wrote:
I propose that we use
Type-Task or Type-ToDo for the management of some items that are not directly bug. Marcus? adrian? is it ok for you?
As a frist step good. I personally would like to destinguish bugs from feature requests. Bugs are bad and I want as little as possible. Feature request are good and I want as many as possible... Another aspect is: Bugs I feel kind of responsible to fix. Feature request I say: If this is really important, someone will do it. (someone not me). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
I propose that we use
Type-Task or Type-ToDo for the management of some items that are not directly bug. Marcus? adrian? is it ok for you?
As a frist step good. I personally would like to destinguish bugs from feature requests. Bugs are bad and I want as little as possible. Feature request are good and I want as many as possible...
Another aspect is: Bugs I feel kind of responsible to fix. Feature request I say: If this is really important, someone will do it. (someone not me).
Ok I like this distinction. I will recategorise. I added some TODO items (like going to the prefecture) Stef
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In Moose we use mainly: Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement and from time to time: Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue Cheers, Doru On 7 Apr 2010, at 16:30, Stéphane Ducasse wrote:
I propose that we use
Type-Task or Type-ToDo for the management of some items that are not directly bug. Marcus? adrian? is it ok for you?
As a frist step good. I personally would like to destinguish bugs from feature requests. Bugs are bad and I want as little as possible. Feature request are good and I want as many as possible...
Another aspect is: Bugs I feel kind of responsible to fix. Feature request I say: If this is really important, someone will do it. (someone not me).
Ok I like this distinction. I will recategorise. I added some TODO items (like going to the prefecture)
Stef
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Sometimes the best solution is not the best solution."
tx I checked the inria task is too complex (the idea is to manage dependency and produce gantt about tasks). Stef
In Moose we use mainly: Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement
and from time to time: Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
Cheers, Doru
On 7 Apr 2010, at 16:30, Stéphane Ducasse wrote:
I propose that we use
Type-Task or Type-ToDo for the management of some items that are not directly bug. Marcus? adrian? is it ok for you?
As a frist step good. I personally would like to destinguish bugs from feature requests. Bugs are bad and I want as little as possible. Feature request are good and I want as many as possible...
Another aspect is: Bugs I feel kind of responsible to fix. Feature request I say: If this is really important, someone will do it. (someone not me).
Ok I like this distinction. I will recategorise. I added some TODO items (like going to the prefecture)
Stef
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Apr 7, 2010 at 10:48 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
tx I checked the inria task is too complex (the idea is to manage dependency and produce gantt about tasks).
Like this: http://trac.edgewall.org/milestone/0.12 ? Laurent Laffont
Stef
In Moose we use mainly: Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement
and from time to time: Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
Cheers, Doru
On 7 Apr 2010, at 16:30, Stéphane Ducasse wrote:
I propose that we use
Type-Task or Type-ToDo for the management of some items that are not
directly bug.
Marcus? adrian? is it ok for you?
As a frist step good. I personally would like to destinguish bugs from feature requests. Bugs are bad and I want as little as possible. Feature request are good and I want as many as possible...
Another aspect is: Bugs I feel kind of responsible to fix. Feature request I say: If this is really important, someone will do it. (someone not me).
Ok I like this distinction. I will recategorise. I added some TODO items (like going to the prefecture)
Stef
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Apr 8, 2010, at 8:56 AM, laurent laffont wrote:
On Wed, Apr 7, 2010 at 10:48 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: tx I checked the inria task is too complex (the idea is to manage dependency and produce gantt about tasks).
Like this: http://trac.edgewall.org/milestone/0.12 ?
I do not know I could not understand it I have the iumpression that we tasks with optionally an order notion but not been forced to enter start date, dependency, estimated number of hours. Stef
Can we alter the placements of the items in the method menu? Sometimes i click just to pixels above and erase a method instead of running the test!
Yes! The sad part of the story is that we changed all the menus in O2 but O2 will never make it. stef On Apr 8, 2010, at 10:05 AM, Fernando olivero wrote:
Can we alter the placements of the items in the method menu?
Sometimes i click just to pixels above and erase a method instead of running the test!
<methodmenus.png>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Can we alter the placements of the items in the method menu?
Yeah, this is an unfortunate placement, however it logically belongs to the group of actions commands. Personally I didn't notice that problem, because I always use Ctrl+T to run the test. In the latest OB with refactoring tools installed you can undo/redo most actions (method definition, class definition, method removal, method definition, method change, and of course all refactorings). Just click on 'refactor --> undo' in case you accidentally deleted/overwrite something.
The sad part of the story is that we changed all the menus in O2 but O2 will never make it.
Shortening the menus is good, but not to the point where logical groups are split into unrelated and messy submenus. Lukas -- Lukas Renggli www.lukas-renggli.ch
Name: OB-SUnitIntegration-lr.25 Author: lr Time: 8 April 2010, 11:12:28 am UUID: 1cb48cf9-d265-4f04-8146-6a594a1b4ce0 Ancestors: OB-SUnitIntegration-lr.24 - put menu item at the top On 8 April 2010 11:02, Lukas Renggli <renggli@gmail.com> wrote:
Can we alter the placements of the items in the method menu?
Yeah, this is an unfortunate placement, however it logically belongs to the group of actions commands.
Personally I didn't notice that problem, because I always use Ctrl+T to run the test.
In the latest OB with refactoring tools installed you can undo/redo most actions (method definition, class definition, method removal, method definition, method change, and of course all refactorings). Just click on 'refactor --> undo' in case you accidentally deleted/overwrite something.
The sad part of the story is that we changed all the menus in O2 but O2 will never make it.
Shortening the menus is good, but not to the point where logical groups are split into unrelated and messy submenus.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
great, much safer placements. But i think now i will force myself to start using cmd-T. Fernando On Apr 8, 2010, at 11:14 AM, Lukas Renggli wrote:
Name: OB-SUnitIntegration-lr.25 Author: lr Time: 8 April 2010, 11:12:28 am UUID: 1cb48cf9-d265-4f04-8146-6a594a1b4ce0 Ancestors: OB-SUnitIntegration-lr.24
- put menu item at the top
On 8 April 2010 11:02, Lukas Renggli <renggli@gmail.com> wrote:
Can we alter the placements of the items in the method menu?
Yeah, this is an unfortunate placement, however it logically belongs to the group of actions commands.
Personally I didn't notice that problem, because I always use Ctrl+T to run the test.
In the latest OB with refactoring tools installed you can undo/redo most actions (method definition, class definition, method removal, method definition, method change, and of course all refactorings). Just click on 'refactor --> undo' in case you accidentally deleted/overwrite something.
The sad part of the story is that we changed all the menus in O2 but O2 will never make it.
Shortening the menus is good, but not to the point where logical groups are split into unrelated and messy submenus.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Apr 8, 2010, at 11:02 AM, Lukas Renggli wrote:
Can we alter the placements of the items in the method menu?
Yeah, this is an unfortunate placement, however it logically belongs to the group of actions commands.
Personally I didn't notice that problem, because I always use Ctrl+T to run the test.
In the latest OB with refactoring tools installed you can undo/redo most actions (method definition, class definition, method removal, method definition, method change, and of course all refactorings). Just click on 'refactor --> undo' in case you accidentally deleted/overwrite something.
The sad part of the story is that we changed all the menus in O2 but O2 will never make it.
Shortening the menus is good, but not to the point where logical groups are split into unrelated and messy submenus.
don't be negative this is not because something does not suit you that it is bad or that others do not like it. stef
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 07/04/2010 17:48, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu:
tx I checked the inria task is too complex (the idea is to manage dependency and produce gantt about tasks).
Stef, If include in our process the concept of periodically perusing the [proposed] tasks and define the dependencies, it may worth the added complexity. My .019999.... -- Cesar Rabak
On Apr 7, 2010, at 15:50 , Stéphane Ducasse wrote:
I propose that we use
Type-Task or Type-ToDo for the management of some items that are not directly bug. Marcus? adrian? is it ok for you?
yes, looks good Adrian
Stef
On Apr 7, 2010, at 3:38 PM, Stéphane Ducasse wrote:
Hi guys
We have bug entries and now I have one question. Do we want to mix or not todo within them? I deleted all the old tasks from the inria web site. Now we could use it.
Do you have experience managing todo (which may be orthogonal to issue and bug trcking)?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Adrian Lienhard -
csrabak＠bol.com.br -
Fernando olivero -
laurent laffont -
Lukas Renggli -
Marcus Denker -
Stéphane Ducasse -
Tudor Girba