Hi Philip and jupiter hacky hackers, I need your comments about Jupiter.
What do you think about the "approval" phase he is talking about? He might want to distinguish between the newly assigned issues whose status is "unresolved" and the reworked and disapproved issues whose status is back to "unresolved". In addition, he might think it would be useful in the approval phase filtered by "resolved" because he (or manager) wants to check the issues which are resolved by the assigned persons if they are approved or not. What do you think? Takuya Forwarded by Takuya Yamashita <[EMAIL PROTECTED]> ----------------------- Original Message ----------------------- From: "Shoup,Allan" <[EMAIL PROTECTED]> To: Takuya Yamashita <[EMAIL PROTECTED]> Date: Tue, 31 Aug 2004 18:39:04 -0500 Subject: RE: Jupiter Enhancement Request ---- The problem that tends to develop is there are multiple code reviews per week and a different developer might be working on each issue. Sometimes other things come up where the code review fixes are postponed. The problem comes in making sure these issues are not forgotten. If I submitted a code issue two weeks ago that has not yet been approved by me, I need to know to remind the developer it is assigned to that it still needs to be done. -----Original Message----- From: Takuya Yamashita [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 6:32 PM To: Shoup,Allan Cc: Jupiter Mailing List Subject: Re: Jupiter Enhancement Request > I suppose what I was compensating for by utilizing only one review was > the "approval phase". That would be one where the reviewer who logged > the issue wants to go back through the issues that he/she logged to > ensure they were resolved satisfactorily. Can you achieve this in one of phases like team phase for example? After individual reworks are done, the reviewers (or team manager) take a look at the satus of review issues by filtering "unresolved" or "resolved" status field. Is this not enough for you? Cheers, Takuya On Mon, 30 Aug 2004 18:00:52 -0500 "Shoup,Allan" <[EMAIL PROTECTED]> wrote: > > I suppose what I was compensating for by utilizing only one review was > the "approval phase". That would be one where the reviewer who logged > the issue wants to go back through the issues that he/she logged to > ensure they were resolved satisfactorily. In the current incarnation > of the plugin, there does not seem to be a good mechanism for this. > This is further complicated when you have multiple reviews that you > have logged issues for that are concurrently being resolved by separate individuals. > What I'm looking for is a way to run a query on a set of reviews to > pull up all the issues that have been marked as resolved that I have > yet to "approve". Any thoughts on the best way to accomplish this? > > Thanks. > > -----Original Message----- > From: Takuya Yamashita [mailto:[EMAIL PROTECTED] > Sent: Friday, August 20, 2004 5:32 AM > To: Shoup,Allan > Cc: Jupiter Mailing List > Subject: Re: Jupiter Enhancement Request > > Hi Allan, > > Sorry for replying late. This email was not read yet until now somehow. > > I apologize you this time and give you our thought. > > > I have a couple requests for it, though. I would like to be able to > > set filters for each phase (Individual, Team, and Rework) and have > > Jupiter automatically apply those filters when I change to that phase. > > This is completely nice idea and what I have thought, but not > implemented. In team phase, the author in the preparation phase would > be the same person in the team phase (the author who address a review > phase (id) would be the moderator in the team phase). Thus the setting > of the team phase would make definitely sense. > > Rework phase would make sense too because the author of the review > session would be the reworker too. > > The question is that should the author of the review control the > setting of the individual phase? Our possible answer is Yes because it > saves a time for the reviewers to set a filter so that they can just > concentrate on a review without any setting of Jupiter. > > In version 2 (which would be comming soon), each review id can control > the item lists in fields (such as Type, Severity, etc) so that users > can define what they want for a specific review id). Hopefully > implementation of the filter setting in each phase would be implement > soon. > > > One other wish I have is that there would be a way to avoid having > > to specify the code review. It would be nice if each project had one > > permanent meeting and every code issue logged would go into that > > meeting. To prevent performance degradation, it would have to have a > > way to archive the resolved code issues that were older than a > > specified threshold to some different accessible repository. I > > understand that this is somewhat divergent from the general strategy > > of Jupiter, so I understand if you wouldn't want to implement this, > however. > > Hmm, our suggestion to avoid the pile of old review issues is that you > can create a different review id for each review phase. Our idea is > that each review phase id separates the file content because of file > conflict in a CVS. if there is a backup repository file which contains > the all reviewed content, and members share the file in a CVS, the > file conflicting would take place more frequently because reviewers > change their own review session files and they are reflected to the > master backup repository file too. Another reason is that users would > not read a half-year-old review content frequently so that the bunch > of review entries with a review filter would annoy users because the > developing file (which was reviewed a long time ago) would change over > the time so that the content of the review file would make sense any > more after time goes by. > > Cheers, > > Takuya > > p.s. this is cc'ing to the jupiter mailing list. > > On Thu, 01 Jul 2004 09:06:36 -0500 > "Shoup,Allan" <[EMAIL PROTECTED]> wrote: > > > > > Hi Takuyay. I'd just like to say that I think your plug-in is great. > > > > I have a couple requests for it, though. I would like to be able to > > set filters for each phase (Individual, Team, and Rework) and have > > Jupiter automatically apply those filters when I change to that phase. > > > > For example, if I was in the Individual phase, I might set my > > filters to only view reviews submitted by myself. When I switch to > > the team phase, I want to see all the code issues where the > > resolution is unset > > > and when I switch to the Rework phase, I want to all issues where > > the status is unresolved and the 'assigned to' is myself. > > > > One other wish I have is that there would be a way to avoid having > > to specify the code review. It would be nice if each project had one > > permanent meeting and every code issue logged would go into that > > meeting. To prevent performance degradation, it would have to have a > > way to archive the resolved code issues that were older than a > > specified threshold to some different accessible repository. I > > understand that this is somewhat divergent from the general strategy > > of Jupiter, so I understand if you wouldn't want to implement this, > however. > > > > Let me know what you think and thanks for this great tool. > > > > Allan Shoup > > Cerner Corporation > > Software Architect - Bedrock > > 2900 Rockcreek Parkway > > Kansas City, MO 64117-2551 > > (816) 201-1778 > > > > > > > > CONFIDENTIALITY NOTICE > > > > This message and any included attachments are from Cerner > > Corporation and are intended only for the addressee. The information > > contained in this message is confidential and may constitute inside > > or non-public information under international, federal, or state securities laws. > > Unauthorized forwarding, printing, copying, distribution, or use of > > such information is strictly prohibited and may be unlawful. If you > > are not the addressee, please promptly delete this message and > > notify the sender of the delivery error by e-mail or you may call > > Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) > > (816)221-1024. > > ---------------------------------------- -- > > > > ================================ > Takuya Yamashita > E-mail: [EMAIL PROTECTED] > ================================ > > > CONFIDENTIALITY NOTICE > > This message and any included attachments are from Cerner Corporation > and are intended only for the addressee. The information contained in > this message is confidential and may constitute inside or non-public > information under international, federal, or state securities laws. > Unauthorized forwarding, printing, copying, distribution, or use of > such information is strictly prohibited and may be unlawful. If you > are not the addressee, please promptly delete this message and notify > the sender of the delivery error by e-mail or you may call Cerner's > corporate offices in Kansas City, Missouri, U.S.A at (+1) > (816)221-1024. > ---------------------------------------- -- ================================ Takuya Yamashita E-mail: [EMAIL PROTECTED] ================================ CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. ---------------------------------------- -- --------------------- Original Message Ends --------------------
