Hi all,
Made some changes to JIRA to help with release planning. Please review this JIRA glossary first:
http://confluence.immuexa.com/display/sq/Process
If the terms don't seem to make sense, then return to the glossary and read them again and again.
I've used JIRA with a wide variety of software teams over the last five years, so please rely upon my experience until it becomes more familiar.
JIRA is used by Apache and many other large open-source projects ... there's truly a "there" there, but only if you relax and use it as it was designed to be used.
The changes:
1. "must-have" = critical priority
2. "desirable" = normal priority
3. "possible" = eventual priority
4. "desirable but complex or risky" = optional priority
5. "published!" = closed
6. "ready for testing" = resolved
7. "internationalization" = moved in with the rest (in 4.1 release)
8. "pango" = moved in with the rest (in 4.1 release)
9. "dormant, residual, historical" = optional priority in someday release
10. two big versions ... "etoys 4.0 - summer 2009" and "etoys 4.1 - winter 2010" (summers will be even numbered, winters will be odd numbered)
The reason for all of this is so that we can actually look at the roadmap and see where we are. Things were too fragmented. They were going against the way JIRA works.
So now, there's three release bins showing on the roadmap:
a. review ... all new stuff goes here and gets moved elsewhere after discussion
b. etoys 4.0 ... current release
c. biz/ed ... these are the non-Etoys items that the business and education teams must do
There will always be these three at the top of the release road map ... click "all versions" to see etoys 4.1, etc.
Anyway, I hope this makes things clearer. As you continue to use JIRA, you'll see that many tools exist that require this functionality. (Try "Find Issues", for example, then click "New".)
So if you're wondering:
* what should I test? Click "Resolved" under Project Summary o see a list of resolved issues. These need testing.
Add a comment saying, "works for me" and then put the change to the update stream and click "Closed" (aka Published)
Would other words be more clear? Perhaps to some. In my opinion, let's all try to learn these five states (scheduled, in progress, resolved, closed) and five priorities (blocker, critical, normal, eventual, optional). They work.
Also, remember ... the best view is "road map" ... it sorts by priority into releases. It also has a nifty green & red progress bar that motivates.
Now, I'm going back into my post-Squeakfest cave for a while ... in the next week or so, please help move things in "review" or "etoys 4.0" that we can't do easily in the next few weeks to "etoys 4.1"
Our overall goal is to have Etoys 4.0 be all green in the roadmap. Another goal is to have zero issues in "review".
Sorry for the draconian changes, but I couldn't get my finger on the pulse of the release the way it was. This is a better way to work.
Tim
At Fri, 21 Aug 2009 23:36:41 -0400, Timothy Falconer wrote:
Hi all,
Made some changes to JIRA to help with release planning. Please review this JIRA glossary first:
http://confluence.immuexa.com/display/sq/Process
If the terms don't seem to make sense, then return to the glossary and read them again and again.
I've used JIRA with a wide variety of software teams over the last five years, so please rely upon my experience until it becomes more familiar.
JIRA is used by Apache and many other large open-source projects ... there's truly a "there" there, but only if you relax and use it as it was designed to be used.
The changes:
- "must-have" = critical priority
We still have a "Blocker" item. Is it merged to "Critical"?
"desirable" = normal priority
"possible" = eventual priority
"desirable but complex or risky" = optional priority
Otherwise these new priorities are better. "Ongoing" is going away, too?
- two big versions ... "etoys 4.0 - summer 2009" and "etoys 4.1 -
winter 2010" (summers will be even numbered, winters will be odd numbered)
Still, the nature of our project (relatively stable working system with very scarse man power) seems that we usually don't have too many blockers and critical ones (we shouldn't). So if timely release is important, "must-have" for a release wouldn't make it really "must-have".
The reason for all of this is so that we can actually look at the roadmap and see where we are. Things were too fragmented. They were going against the way JIRA works.
Ok.
So now, there's three release bins showing on the roadmap:
a. review ... all new stuff goes here and gets moved elsewhere after discussion
b. etoys 4.0 ... current release
c. biz/ed ... these are the non-Etoys items that the business and education teams must do
There will always be these three at the top of the release road map ... click "all versions" to see etoys 4.1, etc.
Much better. Saner prioritizing would be even better.
Anyway, I hope this makes things clearer. As you continue to use JIRA, you'll see that many tools exist that require this functionality. (Try "Find Issues", for example, then click "New".)
Some JIRA questions:
- Can I search for all comments by a registered user (or all issues commented by the user)?
- Can I see the list of "all activities" (all changes on any item) in last 24 hours?
Add a comment saying, "works for me" and then put the change to the update stream and click "Closed" (aka Published)
Hmm, putting the change to the update stream is so far limited to certain users. (And "works for me" just by somebody often is not the right reason to "Close" an item.)
Would other words be more clear? Perhaps to some. In my opinion, let's all try to learn these five states (scheduled, in progress, resolved, closed) and five priorities (blocker, critical, normal, eventual, optional). They work.
Ok. As long as issues are not going away, we can surely work with it and make more changes if necessary.
Also, remember ... the best view is "road map" ... it sorts by priority into releases. It also has a nifty green & red progress bar that motivates.
Now, I'm going back into my post-Squeakfest cave for a while ... in the next week or so, please help move things in "review" or "etoys 4.0" that we can't do easily in the next few weeks to "etoys 4.1"
Our overall goal is to have Etoys 4.0 be all green in the roadmap. Another goal is to have zero issues in "review".
Sorry for the draconian changes, but I couldn't get my finger on the pulse of the release the way it was. This is a better way to work.
Thanks!
-- Yoshiki
On Aug 22, 2009, at 1:08 AM, Yoshiki Ohshima wrote:
At Fri, 21 Aug 2009 23:36:41 -0400, Timothy Falconer wrote:
Hi all,
Made some changes to JIRA to help with release planning. Please review this JIRA glossary first:
http://confluence.immuexa.com/display/sq/Process
If the terms don't seem to make sense, then return to the glossary and read them again and again.
I've used JIRA with a wide variety of software teams over the last five years, so please rely upon my experience until it becomes more familiar.
JIRA is used by Apache and many other large open-source projects ... there's truly a "there" there, but only if you relax and use it as it was designed to be used.
The changes:
- "must-have" = critical priority
We still have a "Blocker" item. Is it merged to "Critical"?
Blockers should be very infrequent. Our definition of Blocker is "something that's preventing someone from getting work done", or "something that will block a release".
Remember also that these priorities are being used by the education and business teams, and by other software groups on the same server.
The ongoing priority is primarily for issues in the "ongoing" release . . . these are used primarily for time logging (regular chats, etc, publicity, etc).
Stuff too general to make their own issue.
"desirable" = normal priority
"possible" = eventual priority
"desirable but complex or risky" = optional priority
Otherwise these new priorities are better. "Ongoing" is going away, too?
BTW, these are the priorities from last April :)
- two big versions ... "etoys 4.0 - summer 2009" and "etoys 4.1 -
winter 2010" (summers will be even numbered, winters will be odd numbered)
Still, the nature of our project (relatively stable working system with very scarse man power) seems that we usually don't have too many blockers and critical ones (we shouldn't). So if timely release is important, "must-have" for a release wouldn't make it really "must-have".
Priorities serve two purposes ... sorting and alerting . . . I see a "blocker" and it's the first thing I talk about, every time. Otherwise they're just a way to work down the list.
The reason for all of this is so that we can actually look at the roadmap and see where we are. Things were too fragmented. They were going against the way JIRA works.
Ok.
So now, there's three release bins showing on the roadmap:
a. review ... all new stuff goes here and gets moved elsewhere after discussion
b. etoys 4.0 ... current release
c. biz/ed ... these are the non-Etoys items that the business and education teams must do
There will always be these three at the top of the release road map ... click "all versions" to see etoys 4.1, etc.
Much better. Saner prioritizing would be even better.
Suggest away, in comments, or simply change priorities yourself. Like a wiki, simply changing something is saying "I think this should be changed to this".
The current priorities come from TRAC and Scott, for the most part.
Anyway, I hope this makes things clearer. As you continue to use JIRA, you'll see that many tools exist that require this functionality. (Try "Find Issues", for example, then click "New".)
Some JIRA questions:
- Can I search for all comments by a registered user (or all issues commented by the user)?
Hmm... interesting, you can search comments, but you search almost everything else :)
Maybe the new JIRA upgrade will have this.
- Can I see the list of "all activities" (all changes on any item) in last 24 hours?
From the "browse" page, click "Updated recently" ... it's not the last 24 hours, but it lets you scan the same way.
Add a comment saying, "works for me" and then put the change to the update stream and click "Closed" (aka Published)
Hmm, putting the change to the update stream is so far limited to certain users. (And "works for me" just by somebody often is not the right reason to "Close" an item.)
I think my initial process page said that software team members verify and push to the stream (#13):
http://confluence.immuexa.com/display/sq/Process
Priorities and code review are the primary function of the software team.
Is this sufficient?
Would other words be more clear? Perhaps to some. In my opinion, let's all try to learn these five states (scheduled, in progress, resolved, closed) and five priorities (blocker, critical, normal, eventual, optional). They work.
Ok. As long as issues are not going away, we can surely work with it and make more changes if necessary.
Also, remember ... the best view is "road map" ... it sorts by priority into releases. It also has a nifty green & red progress bar that motivates.
Now, I'm going back into my post-Squeakfest cave for a while ... in the next week or so, please help move things in "review" or "etoys 4.0" that we can't do easily in the next few weeks to "etoys 4.1"
Our overall goal is to have Etoys 4.0 be all green in the roadmap. Another goal is to have zero issues in "review".
Sorry for the draconian changes, but I couldn't get my finger on the pulse of the release the way it was. This is a better way to work.
Thanks!
-- Yoshiki _______________________________________________ etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On 24.08.2009, at 23:56, Timothy Falconer wrote:
Hmm, putting the change to the update stream is so far limited to certain users. (And "works for me" just by somebody often is not the right reason to "Close" an item.)
I think my initial process page said that software team members verify and push to the stream (#13):
you meant #14?
http://confluence.immuexa.com/display/sq/Process
Priorities and code review are the primary function of the software team.
We should clarify how to "submit code" in step #12.
Also, when resolving in step 12, I guess the resolution should be "ongoing"? The options are Complete, Reject, Duplicate, Unclear, Cannot Reproduce, Ongoing, Test Passed, Test Failed. So "ongoing" would mean "ready for testing"?
And in step 14, how do we mark a closed issue that is not yet put to the update stream"? Or should rather the tester change the resolution to "test passed", and the developer who pushes an update to the stream closes the issue?
As for the other resolutions, who is going to close these issues, and when?
- Bert -
Tim,
On 25.08.2009, at 00:30, Bert Freudenberg wrote:
On 24.08.2009, at 23:56, Timothy Falconer wrote:
Hmm, putting the change to the update stream is so far limited to certain users. (And "works for me" just by somebody often is not the right reason to "Close" an item.)
I think my initial process page said that software team members verify and push to the stream (#13):
you meant #14?
http://confluence.immuexa.com/display/sq/Process
Priorities and code review are the primary function of the software team.
We should clarify how to "submit code" in step #12.
Also, when resolving in step 12, I guess the resolution should be "ongoing"? The options are Complete, Reject, Duplicate, Unclear, Cannot Reproduce, Ongoing, Test Passed, Test Failed. So "ongoing" would mean "ready for testing"?
And in step 14, how do we mark a closed issue that is not yet put to the update stream"? Or should rather the tester change the resolution to "test passed", and the developer who pushes an update to the stream closes the issue?
As for the other resolutions, who is going to close these issues, and when?
- Bert -
Maybe I need to rephrase?
We need a JIRA view showing all issues that got a fix attached and are ready for testing.
And we need a JIRA view showing all issues that were tested and got approved but are not yet pushed to the update stream.
Setting the resolution to "ongoing" as I mused above seems to go against the system. I'm not sure how the "test failed" and "test passed" resolutions fit in.
And something else:
The Roadmap view is quite nice, but it mixes the "resolved" and "closed" issues. Can we change it to put closed ones last? Also, can I restrict it to show just etoys tickets?
- Bert -
On Aug 25, 2009, at 2:52 PM, Bert Freudenberg wrote:
Maybe I need to rephrase?
We need a JIRA view showing all issues that got a fix attached and are ready for testing.
You can click "Resolved" under "Project Summary" . . . anything that's not waiting for a test will be closed right away (cannot reproduce, etc).
And we need a JIRA view showing all issues that were tested and got approved but are not yet pushed to the update stream.
As my earlier email suggested, we do the "close" and the "push" at the same time, right after a software meet.
Setting the resolution to "ongoing" as I mused above seems to go against the system. I'm not sure how the "test failed" and "test passed" resolutions fit in.
And something else:
The Roadmap view is quite nice, but it mixes the "resolved" and "closed" issues. Can we change it to put closed ones last? Also, can I restrict it to show just etoys tickets?
We're upgrading to the newest JIRA this week ... I'm guessing there's a boatload of new reporting functionality, so let's revisit when it's done.
Tim
On Aug 24, 2009, at 6:30 PM, Bert Freudenberg wrote:
On 24.08.2009, at 23:56, Timothy Falconer wrote:
Hmm, putting the change to the update stream is so far limited to certain users. (And "works for me" just by somebody often is not the right reason to "Close" an item.)
I think my initial process page said that software team members verify and push to the stream (#13):
you meant #14?
Yes.
http://confluence.immuexa.com/display/sq/Process
Priorities and code review are the primary function of the software team.
We should clarify how to "submit code" in step #12.
Done.
Also, when resolving in step 12, I guess the resolution should be "ongoing"? The options are Complete, Reject, Duplicate, Unclear, Cannot Reproduce, Ongoing, Test Passed, Test Failed. So "ongoing" would mean "ready for testing"?
When you click "resolve", the word "complete" means, "my work is complete". With small groups, we simply re-open the issue when someone's test doesn't pass. (I never use "test passed" and "test failed").
And in step 14, how do we mark a closed issue that is not yet put to the update stream"? Or should rather the tester change the resolution to "test passed", and the developer who pushes an update to the stream closes the issue?
Issues should be closed by someone on the software team at the same time as pushing the changeset. I've modified the process page to make this clearer.
As for the other resolutions, who is going to close these issues, and when?
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On 31.08.2009, at 15:46, Timothy Falconer wrote:
When you click "resolve", the word "complete" means, "my work is complete". With small groups, we simply re-open the issue when someone's test doesn't pass.
Tim,
do we want to always resolve when there is a change set? See chat log below.
[04.09.09 11:11:15] Bert: hi scott: when you attach a fix to jira, our workflow now demands to resolve the ticket. all resolved but not-yet- closed tickets are the ones that need testing. This actually makes some sense ;) http://wiki.squeakland.org/display/sq/Process [04.09.09 11:12:19] Scott: yes, I know that, though I haven't been practicing it much ;-) [04.09.09 11:12:58] Bert: ah, okay. I thought you forgot, seeing the new attachments [04.09.09 11:16:08] Scott: not always clear what to do. e.g. SQ-267, i posted a fileout that carries out the suggestion of the ticket, but no one ever commented on the ticket, no one ever said yes we should do this. So I put the fileout onto the ticket but didn't want to "resolve" it without there being some agreement that it was something we wanted. [04.09.09 11:17:21] Bert: I understand, but that's only the next step. Resolving means putting up for review now [04.09.09 11:17:53] Bert: and the milestone should be changed to the current one too if we want to deal with it soon. [04.09.09 11:19:15] Scott: So in the case of sq-267 you think I should "resolve" it? [04.09.09 11:20:23] Bert: yes, and move to summer release, and assign to yourself, all in one go [04.09.09 11:20:57] Bert: that's all in the "resolve" page [04.09.09 11:24:36] Scott: In terms of the "proess" page, however, I'd say that Sq-267 might count as still being in the Sifting phase, because people have not commented on it; it's a ui change that adds more items to the precious supplies-bin real-estate. And if we do decide we want it, the choice of where the two new items should appear in the supplies bin will have to be made (my fileout puts them at the end). Is this all really stuff that should count as "resolved"? [04.09.09 11:27:38] Bert: it's resolved in a way. whether we like it or not is up for discussion. the discussion starts by marking it resolved, it's easier to discuss code. you should put exactly what you just wrote into the resolve comment. it feels odd I agree, but we may just say yep, that's good enough, ship it. [04.09.09 11:28:07] Scott: okay -- thanks.
And since this affects the UI in a way, how do we get someone of the edu team to look at it? They rarely (if ever) comment on issues. It's also not part of the workflow you proposed.
- Bert -
On Sep 4, 2009, at 5:42 AM, Bert Freudenberg wrote:
On 31.08.2009, at 15:46, Timothy Falconer wrote:
When you click "resolve", the word "complete" means, "my work is complete". With small groups, we simply re-open the issue when someone's test doesn't pass.
Tim,
do we want to always resolve when there is a change set? See chat log below.
[04.09.09 11:11:15] Bert: hi scott: when you attach a fix to jira, our workflow now demands to resolve the ticket. all resolved but not- yet-closed tickets are the ones that need testing. This actually makes some sense ;) http://wiki.squeakland.org/display/sq/Process [04.09.09 11:12:19] Scott: yes, I know that, though I haven't been practicing it much ;-) [04.09.09 11:12:58] Bert: ah, okay. I thought you forgot, seeing the new attachments [04.09.09 11:16:08] Scott: not always clear what to do. e.g. SQ-267, i posted a fileout that carries out the suggestion of the ticket, but no one ever commented on the ticket, no one ever said yes we should do this. So I put the fileout onto the ticket but didn't want to "resolve" it without there being some agreement that it was something we wanted. [04.09.09 11:17:21] Bert: I understand, but that's only the next step. Resolving means putting up for review now [04.09.09 11:17:53] Bert: and the milestone should be changed to the current one too if we want to deal with it soon. [04.09.09 11:19:15] Scott: So in the case of sq-267 you think I should "resolve" it? [04.09.09 11:20:23] Bert: yes, and move to summer release, and assign to yourself, all in one go [04.09.09 11:20:57] Bert: that's all in the "resolve" page [04.09.09 11:24:36] Scott: In terms of the "proess" page, however, I'd say that Sq-267 might count as still being in the Sifting phase, because people have not commented on it; it's a ui change that adds more items to the precious supplies-bin real-estate. And if we do decide we want it, the choice of where the two new items should appear in the supplies bin will have to be made (my fileout puts them at the end). Is this all really stuff that should count as "resolved"? [04.09.09 11:27:38] Bert: it's resolved in a way. whether we like it or not is up for discussion. the discussion starts by marking it resolved, it's easier to discuss code. you should put exactly what you just wrote into the resolve comment. it feels odd I agree, but we may just say yep, that's good enough, ship it. [04.09.09 11:28:07] Scott: okay -- thanks.
And since this affects the UI in a way, how do we get someone of the edu team to look at it? They rarely (if ever) comment on issues. It's also not part of the workflow you proposed.
Resolved means "I've completed my coding".
Then comes code review / testing. If there's any further discussion, the issue is "reopened".
If we decide we don't want it, the issue is "rejected".
If we want the ed team to comment, we reopen, attach a screenshot, and send a note to the ed team.
The ed team also has the option to comment on betas, which we'll have monthly, so there's plenty of time to make changes.
Does this help?
Tim
Bert, You said: "And since this affects the UI in a way, how do we get someone of the edu team to look at it? They rarely (if ever) comment on issues. It's also not part of the workflow you proposed."
I agree. It is a very good idea to have people in the edu team see these issues sooner rather than later in the process. Many times I have felt like I wanted to know more about what I am reading in the lists and yet I do not have the technical knowledge to understand what is going on and I don't wish to slow down what is already a complex process by asking for explanations that may be painfully basic and obvious to developers.
I would be very glad to try new changes and comment if someone will teach me how to join the stream of changes that may or may not be included in a release. I am teaching at an elementary school again this year and have a 100 students who will happily join me in experimenting with new ideas every week. Regards, Kathleen
---- Original message ----
Date: Fri, 4 Sep 2009 11:42:37 +0200 From: Bert Freudenberg bert@freudenbergs.de Subject: Re: [etoys-dev] jira re-arrangement To: etoys dev etoys-dev@squeakland.org
On 31.08.2009, at 15:46, Timothy Falconer wrote:
When you click "resolve", the word "complete" means, "my work is complete". With small groups, we simply re-open the issue when someone's test doesn't pass.
Tim,
do we want to always resolve when there is a change set? See chat log below.
[04.09.09 11:11:15] Bert: hi scott: when you attach a fix to jira, our workflow now demands to resolve the ticket. all resolved but not-yet- closed tickets are the ones that need testing. This actually makes some sense ;) http://wiki.squeakland.org/display/sq/Process [04.09.09 11:12:19] Scott: yes, I know that, though I haven't been practicing it much ;-) [04.09.09 11:12:58] Bert: ah, okay. I thought you forgot, seeing the new attachments [04.09.09 11:16:08] Scott: not always clear what to do. e.g. SQ-267, i posted a fileout that carries out the suggestion of the ticket, but no one ever commented on the ticket, no one ever said yes we should do this. So I put the fileout onto the ticket but didn't want to "resolve" it without there being some agreement that it was something we wanted. [04.09.09 11:17:21] Bert: I understand, but that's only the next step. Resolving means putting up for review now [04.09.09 11:17:53] Bert: and the milestone should be changed to the current one too if we want to deal with it soon. [04.09.09 11:19:15] Scott: So in the case of sq-267 you think I should "resolve" it? [04.09.09 11:20:23] Bert: yes, and move to summer release, and assign to yourself, all in one go [04.09.09 11:20:57] Bert: that's all in the "resolve" page [04.09.09 11:24:36] Scott: In terms of the "proess" page, however, I'd say that Sq-267 might count as still being in the Sifting phase, because people have not commented on it; it's a ui change that adds more items to the precious supplies-bin real-estate. And if we do decide we want it, the choice of where the two new items should appear in the supplies bin will have to be made (my fileout puts them at the end). Is this all really stuff that should count as "resolved"? [04.09.09 11:27:38] Bert: it's resolved in a way. whether we like it or not is up for discussion. the discussion starts by marking it resolved, it's easier to discuss code. you should put exactly what you just wrote into the resolve comment. it feels odd I agree, but we may just say yep, that's good enough, ship it. [04.09.09 11:28:07] Scott: okay -- thanks.
And since this affects the UI in a way, how do we get someone of the edu team to look at it? They rarely (if ever) comment on issues. It's also not part of the workflow you proposed.
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Hi Kathleen,
go to Squeakland, click download, click Etoys-latest-Beta-ToGo.zip. This will work on Mac, Windows, and Linux. It's the best way to test the latest changes, because it neither requires installation nor will it overwrite your working installation.
- Bert -
On 04.09.2009, at 16:04, kharness@illinois.edu wrote:
Bert, You said: "And since this affects the UI in a way, how do we get someone of the edu team to look at it? They rarely (if ever) comment on issues. It's also not part of the workflow you proposed."
I agree. It is a very good idea to have people in the edu team see these issues sooner rather than later in the process. Many times I have felt like I wanted to know more about what I am reading in the lists and yet I do not have the technical knowledge to understand what is going on and I don't wish to slow down what is already a complex process by asking for explanations that may be painfully basic and obvious to developers.
I would be very glad to try new changes and comment if someone will teach me how to join the stream of changes that may or may not be included in a release. I am teaching at an elementary school again this year and have a 100 students who will happily join me in experimenting with new ideas every week. Regards, Kathleen
---- Original message ----
Date: Fri, 4 Sep 2009 11:42:37 +0200 From: Bert Freudenberg bert@freudenbergs.de Subject: Re: [etoys-dev] jira re-arrangement To: etoys dev etoys-dev@squeakland.org
On 31.08.2009, at 15:46, Timothy Falconer wrote:
When you click "resolve", the word "complete" means, "my work is complete". With small groups, we simply re-open the issue when someone's test doesn't pass.
Tim,
do we want to always resolve when there is a change set? See chat log below.
[04.09.09 11:11:15] Bert: hi scott: when you attach a fix to jira, our workflow now demands to resolve the ticket. all resolved but not-yet- closed tickets are the ones that need testing. This actually makes some sense ;) http://wiki.squeakland.org/display/sq/Process [04.09.09 11:12:19] Scott: yes, I know that, though I haven't been practicing it much ;-) [04.09.09 11:12:58] Bert: ah, okay. I thought you forgot, seeing the new attachments [04.09.09 11:16:08] Scott: not always clear what to do. e.g. SQ-267, i posted a fileout that carries out the suggestion of the ticket, but no one ever commented on the ticket, no one ever said yes we should do this. So I put the fileout onto the ticket but didn't want to "resolve" it without there being some agreement that it was something we wanted. [04.09.09 11:17:21] Bert: I understand, but that's only the next step. Resolving means putting up for review now [04.09.09 11:17:53] Bert: and the milestone should be changed to the current one too if we want to deal with it soon. [04.09.09 11:19:15] Scott: So in the case of sq-267 you think I should "resolve" it? [04.09.09 11:20:23] Bert: yes, and move to summer release, and assign to yourself, all in one go [04.09.09 11:20:57] Bert: that's all in the "resolve" page [04.09.09 11:24:36] Scott: In terms of the "proess" page, however, I'd say that Sq-267 might count as still being in the Sifting phase, because people have not commented on it; it's a ui change that adds more items to the precious supplies-bin real-estate. And if we do decide we want it, the choice of where the two new items should appear in the supplies bin will have to be made (my fileout puts them at the end). Is this all really stuff that should count as "resolved"? [04.09.09 11:27:38] Bert: it's resolved in a way. whether we like it or not is up for discussion. the discussion starts by marking it resolved, it's easier to discuss code. you should put exactly what you just wrote into the resolve comment. it feels odd I agree, but we may just say yep, that's good enough, ship it. [04.09.09 11:28:07] Scott: okay -- thanks.
And since this affects the UI in a way, how do we get someone of the edu team to look at it? They rarely (if ever) comment on issues. It's also not part of the workflow you proposed.
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Bert, Thanks, I'll do it today. Kathleen
---- Original message ----
Date: Fri, 4 Sep 2009 16:16:22 +0200 From: Bert Freudenberg bert@freudenbergs.de Subject: Re: [etoys-dev] jira re-arrangement To: kharness@illinois.edu Cc: etoys dev etoys-dev@squeakland.org
Hi Kathleen,
go to Squeakland, click download, click Etoys-latest-Beta-ToGo.zip. This will work on Mac, Windows, and Linux. It's the best way to test the latest changes, because it neither requires installation nor will it overwrite your working installation.
- Bert -
On 04.09.2009, at 16:04, kharness@illinois.edu wrote:
Bert, You said: "And since this affects the UI in a way, how do we get someone of the edu team to look at it? They rarely (if ever) comment on issues. It's also not part of the workflow you proposed."
I agree. It is a very good idea to have people in the edu team see these issues sooner rather than later in the process. Many times I have felt like I wanted to know more about what I am reading in the lists and yet I do not have the technical knowledge to understand what is going on and I don't wish to slow down what is already a complex process by asking for explanations that may be painfully basic and obvious to developers.
I would be very glad to try new changes and comment if someone will teach me how to join the stream of changes that may or may not be included in a release. I am teaching at an elementary school again this year and have a 100 students who will happily join me in experimenting with new ideas every week. Regards, Kathleen
---- Original message ----
Date: Fri, 4 Sep 2009 11:42:37 +0200 From: Bert Freudenberg bert@freudenbergs.de Subject: Re: [etoys-dev] jira re-arrangement To: etoys dev etoys-dev@squeakland.org
On 31.08.2009, at 15:46, Timothy Falconer wrote:
When you click "resolve", the word "complete" means, "my work is complete". With small groups, we simply re-open the issue when someone's test doesn't pass.
Tim,
do we want to always resolve when there is a change set? See chat log below.
[04.09.09 11:11:15] Bert: hi scott: when you attach a fix to jira, our workflow now demands to resolve the ticket. all resolved but not-yet- closed tickets are the ones that need testing. This actually makes some sense ;) http://wiki.squeakland.org/display/sq/Process [04.09.09 11:12:19] Scott: yes, I know that, though I haven't been practicing it much ;-) [04.09.09 11:12:58] Bert: ah, okay. I thought you forgot, seeing the new attachments [04.09.09 11:16:08] Scott: not always clear what to do. e.g. SQ-267, i posted a fileout that carries out the suggestion of the ticket, but no one ever commented on the ticket, no one ever said yes we should do this. So I put the fileout onto the ticket but didn't want to "resolve" it without there being some agreement that it was something we wanted. [04.09.09 11:17:21] Bert: I understand, but that's only the next step. Resolving means putting up for review now [04.09.09 11:17:53] Bert: and the milestone should be changed to the current one too if we want to deal with it soon. [04.09.09 11:19:15] Scott: So in the case of sq-267 you think I should "resolve" it? [04.09.09 11:20:23] Bert: yes, and move to summer release, and assign to yourself, all in one go [04.09.09 11:20:57] Bert: that's all in the "resolve" page [04.09.09 11:24:36] Scott: In terms of the "proess" page, however, I'd say that Sq-267 might count as still being in the Sifting phase, because people have not commented on it; it's a ui change that adds more items to the precious supplies-bin real-estate. And if we do decide we want it, the choice of where the two new items should appear in the supplies bin will have to be made (my fileout puts them at the end). Is this all really stuff that should count as "resolved"? [04.09.09 11:27:38] Bert: it's resolved in a way. whether we like it or not is up for discussion. the discussion starts by marking it resolved, it's easier to discuss code. you should put exactly what you just wrote into the resolve comment. it feels odd I agree, but we may just say yep, that's good enough, ship it. [04.09.09 11:28:07] Scott: okay -- thanks.
And since this affects the UI in a way, how do we get someone of the edu team to look at it? They rarely (if ever) comment on issues. It's also not part of the workflow you proposed.
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
At Mon, 24 Aug 2009 17:56:58 -0400, Timothy Falconer wrote:
- "must-have" = critical priority
We still have a "Blocker" item. Is it merged to "Critical"?
Blockers should be very infrequent. Our definition of Blocker is "something that's preventing someone from getting work done", or "something that will block a release".
Blockers are very infrequent, yes, and that is the argument that maybe we don't need it (or we don't have to use it).
The only one Blocker we have now is not "something that's preventing someone from getting work done". And if it is "something that will block a release", what is the difference it has from "must-have"?
Remember also that these priorities are being used by the education and business teams, and by other software groups on the same server.
Ah, other software groups... So we may just avoid it, if we want.
The ongoing priority is primarily for issues in the "ongoing" release . . . these are used primarily for time logging (regular chats, etc, publicity, etc).
I don't understand it but sounds like I can just ignore it.
Otherwise these new priorities are better. "Ongoing" is going away, too?
BTW, these are the priorities from last April :)
Right. The new road map is better.
Still, the nature of our project (relatively stable working system with very scarse man power) seems that we usually don't have too many blockers and critical ones (we shouldn't). So if timely release is important, "must-have" for a release wouldn't make it really "must-have".
Priorities serve two purposes ... sorting and alerting . . . I see a "blocker" and it's the first thing I talk about, every time. Otherwise they're just a way to work down the list.
I again don't understand it well... Isn't sorting for alerting? (But never mind. There is always different channels to talk about the importance of issues anyway.)
Much better. Saner prioritizing would be even better.
Suggest away, in comments, or simply change priorities yourself. Like a wiki, simply changing something is saying "I think this should be changed to this".
The current priorities come from TRAC and Scott, for the most part.
At least the release road map part is simplified so I think I understand it better.
- Can I search for all comments by a registered user (or all issues commented by the user)?
Hmm... interesting, you can search comments, but you search almost everything else :)
Maybe the new JIRA upgrade will have this.
Ok.
- Can I see the list of "all activities" (all changes on any item) in last 24 hours?
From the "browse" page, click "Updated recently" ... it's not the last 24 hours, but it lets you scan the same way.
Ah, good, thanks. This is useful.
Add a comment saying, "works for me" and then put the change to the update stream and click "Closed" (aka Published)
Hmm, putting the change to the update stream is so far limited to certain users. (And "works for me" just by somebody often is not the right reason to "Close" an item.)
I think my initial process page said that software team members verify and push to the stream (#13):
http://confluence.immuexa.com/display/sq/Process
Priorities and code review are the primary function of the software team.
Is this sufficient?
The text in the "jira re-arrangement" email was written to the community, right?
Surely reviews and reports that say the code works for some community member is useful and important, but it shouldn't be automatically tied to "Closed" and "Published" status, I thought.
-- Yoshiki
On Aug 24, 2009, at 6:39 PM, Yoshiki Ohshima wrote:
Add a comment saying, "works for me" and then put the change to the update stream and click "Closed" (aka Published)
Hmm, putting the change to the update stream is so far limited to certain users. (And "works for me" just by somebody often is not the right reason to "Close" an item.)
I think my initial process page said that software team members verify and push to the stream (#13):
http://confluence.immuexa.com/display/sq/Process
Priorities and code review are the primary function of the software team.
Is this sufficient?
The text in the "jira re-arrangement" email was written to the community, right?
Surely reviews and reports that say the code works for some community member is useful and important, but it shouldn't be automatically tied to "Closed" and "Published" status, I thought.
-- Yoshiki
Only software team members can close (publish) an issue (the people on the squeakland.org about people page).
I'm not sure I wired it up, but we can make team members the only ones able to schedule and prioritize an issue.
These are typically tasks performed by project managers ... in our case, the team is the "project manager".
Limiting the size of the team just makes things more manageable, anyone can volunteer for the team.
Tim
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
kharness＠illinois.edu -
Timothy Falconer -
Yoshiki Ohshima