Brett Porter wrote:
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?
Yes.
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.
OK, sounds good. So in the long run we'd keep Unscheduled (as a
version), which is a good name - easy to understand what it means for all.
- [ ] 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.
Yes, that's what I meant - need to exist as a version in JIRA.
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 :)
What is your definition of site and documentation. I'm not sure I see
how you mean. For me site is project related and documentation is
product related.
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 :)
Now that'd be a cool feature. Wouldn't it be possible for a skin to
access the issueManagement element of the pom? Then we could add an
optional link on every generated page that goes to the issue managing
system:
<a href="url/to/issuemanagement/create/new/issue">Report an error
with this page</a>
Can a skin have a configuration section like a plugin? Otherwise we
might use a property from the pom. Would be nice to be able to switch
this on/off in some way.
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).
Yea, I just stumbled across such an issue in MPIR. I'll just clone it.
Thanks!
Brett
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
