On 02/08/2007, at 5:31 AM, Dennis Lundberg wrote:
Excellent stuff Brett. Let me know if I can help.
Most of this is equally important for plugins and other maven sub
projects. We should try to make an additional, more general,
description of "versions" that is not tied to MNG.
Agreed, I figured I'd just start here. I can probably change the 2's
to 1's and for the rest folks can do the math :)
- [ ] Backlog - issues that have not been reviewed for a version
assignment (and may be duplicates, won't fix,
unreproducible,
etc.)
- [ ] Unscheduled - new issues that haven't been reviewed yet
Hmm, has anyone looked at issues that are in Backlog? If not, what
is the difference between Backlog and Unassigned?
I assume you mean Unscheduled, not Unassigned?
Some people have given it a once over, it just needs to keep going
until empty. Backlog is really for things that pre-date being
diligent with JIRA :) We should aim to reduce and eventually remove it.
- [ ] actions
- [ ] rename 2.1.x to 2.1
- [ ] create 2.1.x after 2.1
Don't we need 2.1.x *before* 2.1 is released so that we can move
"known issues" to it before the release?
Hmm, do you mean need it before as in it must exist to use, or it is
scheduled before 2.1?
It's currently used as things that might go into 2.1, but I've seen
it look confusing because it behaves differently to 2.0.x (clearly
after 2.0, where 2.0 is already released). So I'm suggesting we
reverse the naming and use "2.1" for things going into 2.1, and 2.1.x
for things we know will remain issues in 2.1 and will be fixed in
2.1.x. I agree that it needs to exist as a version in JIRA whenever
2.1 does.
How do we educate our users (and ourselves for that matter) on the
difference between documentation and site? Perhaps we can make the
pages look slightly different: a special title prefix/suffix, color
scheme, menu struture.
my hope is that docs are distributed, site is not :) I think it will
be a case that users rarely care about the site, and only the docs,
so they'll file in the right place. And if we can put links on all
pages that say how to report an issue with that page, that'd be even
better :)
But we don't have that separation yet anyway...
- [ ] If an issue is too large - clone it to create
smaller and more manageable issues
Sounds good. I prefer this to subtasks (which should be reserved for
when a big task is composed of a set of steps that are all required
to complete it).
Thanks!
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]