Hi Takuya,
This is starting to sound like something that might be appropriate for a Hackystat analysis; he wants to start aggregating together information across multiple reviews over a long period of time.
My other thought is that I'd want to think about the trade-off of making Jupiter's built-in process more complicated against the benefits to this particular review context. The more complex and heavyweight we make Jupiter, the less easily used it is. Maybe there's a way to provide this and keep it lightweight, but perhaps we need to gain a bit more experience with the tool before deciding how to proceed.
Cheers, Philip
--On Tuesday, August 31, 2004 2:13 PM -1000 Takuya Yamashita <[EMAIL PROTECTED]> wrote:
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
separate individuals.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 bysomehow.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 nowphase.
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
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
phase.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> > 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
securities laws.> contained in this message is confidential and may constitute inside > or non-public information under international, federal, or state> 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 --------------------
