Hi,
late I think many issues are coming up on the lists and we're not
dealing with resolving them effectively because, as is natural, people
have different priorities or are generally just thinking about different
things that may be interesting or pressing.
The three things of late I can think of is the development process
thread, the integration testing thread, and a discussion of best
practices which fell by the way side a month ago. So I intentionally
picked up Brett's start at codifying the dev process so that at least
two of us are on the same page and try and use that momentum to draw
other people into the discussion. I talked to a couple of subversion
developers (thanks to Garrett Rooney and Paul Querna), read Pragmatic
Version Control, talked to Jesse and Brett and found what useful links I
could find. I put it all together here:
After this I think we should deal with the integration test issues, and
then I'd like to work through the best practices listed in the wiki:
I'm not sure what would work best in terms of keeping the threads of
thought visible when they pass out of the current thread on the mailing
list but here's my idea based on notions in David Allen's "Getting
Things Done" which is a fairly practical way of working through a series
of issues. It basically boils down to collecting all issues that are
important, putting those notions somewhere safe and then prioritizing
them so they can be worked on. This is a little different where it's not
an individual but a group of people but we can use JIRA to collect the
issues and maybe the devs can vote to try and give some priority to the
list.
the priority is set then as a group we work through the issues and
try to work through them one to three issues at a time and stick with
them until we have a resolution. What I would like is a way for anyone
interested to be able to pick up immediately and help. I'm all open to
ideas but I don't think we're dealing effectively with our own issues
because we have no locus to work because the email list is too hard to
keep track of for a lot of people.
Maybe something other then JIRA would work but we need to collect, store
safely, prioritize the short list of issues and anyone who wants to see
where we are in resolving those issues should be able to see in a few
minutes where we are. I think it would be easy enough to setup a JIRA
project and try it. If it doesn't work then we'll look for something
else. I know this type of setup definitely helps me for issues tracked
at the Maven TLP level:
Any thoughts?
At any rate I think the short list now is:
1. Dev process
2. Integration Testing
3. Prioritize best practices and start picking them off
course anyone is free to modify this list before a decision is made
on priority. Just trying to get the ball rolling, and hopefully keep it
rolling.

I like this approach since we can put the discussion of conceptual issues in
jira, gathering comments on it, as we would on an email chain a
decision is being reached in the jira issue, we can boil the points down to
a wiki page. Then link back to the original conceptual jira tickets with
the implementation jira tickets. We can also use the roadmap jira
functionality to point conceptual components to future target releases.

thing I would like to add is that while the volume of our email lists
really makes performing these kinds of discussions very difficult, we are
trained to check out email frequentlyand without some automated reminder
atrophy of the jira ticket might again happen. Perhaps we can wire up an
email reminder system to the jira tickets that are under active review

jesse

1/3/06, Jason van Zyl <jason (AT) maven (DOT) orgwrote:

Hi,

late I think many issues are coming up on the lists and we're not
dealing with resolving them effectively because, as is natural, people
have different priorities or are generally just thinking about different
things that may be interesting or pressing.

The three things of late I can think of is the development process
thread, the integration testing thread, and a discussion of best
practices which fell by the way side a month ago. So I intentionally
picked up Brett's start at codifying the dev process so that at least
two of us are on the same page and try and use that momentum to draw
other people into the discussion. I talked to a couple of subversion
developers (thanks to Garrett Rooney and Paul Querna), read Pragmatic
Version Control, talked to Jesse and Brett and found what useful links I
could find. I put it all together here:

After this I think we should deal with the integration test issues, and
then I'd like to work through the best practices listed in the wiki:
--

I'm not sure what would work best in terms of keeping the threads of
thought visible when they pass out of the current thread on the mailing
list but here's my idea based on notions in David Allen's "Getting
Things Done" which is a fairly practical way of working through a series
of issues. It basically boils down to collecting all issues that are
important, putting those notions somewhere safe and then prioritizing
them so they can be worked on. This is a little different where it's not
an individual but a group of people but we can use JIRA to collect the
issues and maybe the devs can vote to try and give some priority to the
list.

the priority is set then as a group we work through the issues and
try to work through them one to three issues at a time and stick with
them until we have a resolution. What I would like is a way for anyone
interested to be able to pick up immediately and help. I'm all open to
ideas but I don't think we're dealing effectively with our own issues
because we have no locus to work because the email list is too hard to
keep track of for a lot of people.

Maybe something other then JIRA would work but we need to collect, store
safely, prioritize the short list of issues and anyone who wants to see
where we are in resolving those issues should be able to see in a few
minutes where we are. I think it would be easy enough to setup a JIRA
project and try it. If it doesn't work then we'll look for something
else. I know this type of setup definitely helps me for issues tracked
at the Maven TLP level:

Any thoughts?

At any rate I think the short list now is:

1. Dev process
2. Integration Testing
3. Prioritize best practices and start picking them off

course anyone is free to modify this list before a decision is made
on priority. Just trying to get the ball rolling, and hopefully keep it
rolling.

--

jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

Three people can keep a secret provided two of them are dead.

-- Unknown

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
--

>
--
I'm not sure what would work best in terms of keeping the threads of
thought visible when they pass out of the current thread on the mailing
list but here's my idea based on notions in David Allen's "Getting
Things Done" which is a fairly practical way of working through a series
of issues. It basically boils down to collecting all issues that are
important, putting those notions somewhere safe and then prioritizing
them so they can be worked on. This is a little different where it's not
an individual but a group of people but we can use JIRA to collect the
issues and maybe the devs can vote to try and give some priority to the
list.

I do agree with all this but I think we still need the list to discuss
things. JIRA is not good for discussions. we agree about a
strategy/Stuff to do then jira is the best place, I agree.

, I was thinking that the crux of this email was trying to determine was
'Where should these things be discussed?' Email is the classic traditional
place to do it, but discussions have been getting dropped on here and Jira
was a proposed solution. Perhaps someone just needs to keep bumping these
discussion topics up :)

jesse

Jesse McConnell wrote:
I like this approach since we can put the discussion of conceptual issues in
jira, gathering comments on it, as we would on an email chain a
decision is being reached in the jira issue, we can boil the points down to
a wiki page. Then link back to the original conceptual jira tickets with
the implementation jira tickets. We can also use the roadmap jira
functionality to point conceptual components to future target releases.

thing I would like to add is that while the volume of our email lists
really makes performing these kinds of discussions very difficult, we are
trained to check out email frequentlyand without some automated reminder
atrophy of the jira ticket might again happen. Perhaps we can wire up an
email reminder system to the jira tickets that are under active review

We can have all unresolved issues pushed to the dev list at any desired
interval. I think that's a good idea. Maybe a weekly reminder.

jesse

1/3/06, Jason van Zyl <jason (AT) maven (DOT) orgwrote:
>Hi,
>>
>late I think many issues are coming up on the lists and we're not
>dealing with resolving them effectively because, as is natural, people
>have different priorities or are generally just thinking about different
>things that may be interesting or pressing.
>>
>The three things of late I can think of is the development process
>thread, the integration testing thread, and a discussion of best
>practices which fell by the way side a month ago. So I intentionally
>picked up Brett's start at codifying the dev process so that at least
>two of us are on the same page and try and use that momentum to draw
>other people into the discussion. I talked to a couple of subversion
>developers (thanks to Garrett Rooney and Paul Querna), read Pragmatic
>Version Control, talked to Jesse and Brett and found what useful links I
>could find. I put it all together here:
>>
>
>>
>After this I think we should deal with the integration test issues, and
>then I'd like to work through the best practices listed in the wiki:
>>
>>
>
>>
>I'm not sure what would work best in terms of keeping the threads of
>thought visible when they pass out of the current thread on the mailing
>list but here's my idea based on notions in David Allen's "Getting
>Things Done" which is a fairly practical way of working through a series
>of issues. It basically boils down to collecting all issues that are
>important, putting those notions somewhere safe and then prioritizing
>them so they can be worked on. This is a little different where it's not
>an individual but a group of people but we can use JIRA to collect the
>issues and maybe the devs can vote to try and give some priority to the
>list.
>>
>the priority is set then as a group we work through the issues and
>try to work through them one to three issues at a time and stick with
>them until we have a resolution. What I would like is a way for anyone
>interested to be able to pick up immediately and help. I'm all open to
>ideas but I don't think we're dealing effectively with our own issues
>because we have no locus to work because the email list is too hard to
>keep track of for a lot of people.
>>
>Maybe something other then JIRA would work but we need to collect, store
>safely, prioritize the short list of issues and anyone who wants to see
>where we are in resolving those issues should be able to see in a few
>minutes where we are. I think it would be easy enough to setup a JIRA
>project and try it. If it doesn't work then we'll look for something
>else. I know this type of setup definitely helps me for issues tracked
>at the Maven TLP level:
>>
>
>>
>Any thoughts?
>>
>At any rate I think the short list now is:
>>
>1. Dev process
>2. Integration Testing
>3. Prioritize best practices and start picking them off
>>
>course anyone is free to modify this list before a decision is made
>on priority. Just trying to get the ball rolling, and hopefully keep it
>rolling.
>>
>--
>>
>jvz.
>>
>Jason van Zyl
>jason at maven.org
>http://maven.apache.org
>>
>Three people can keep a secret provided two of them are dead.
>>
>-- Unknown
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
>>
>>

actually, is jira accepting emails as comments yet?
that might be another way to work it using both methods, kinda spammy but
might be functional
jesse

Jesse McConnell wrote:

, I was thinking that the crux of this email was trying to determine was
'Where should these things be discussed?' Email is the classic traditional
place to do it, but discussions have been getting dropped on here and Jira
was a proposed solution. Perhaps someone just needs to keep bumping these
discussion topics up :)

The discussion of what to resolve will happen on the list or in irc but
then get populated in JIRA so that what's up for discussion gets
captured. JIRA can ping the list with unresolved issues and as we are
discussing the issues I think someone needs to act as secretary and
capture the salient ideas in the wiki. So for the dev process stuff I
created a document and steward that document to completion. I think the
same would go with the integration tests where this is something that
Vincent is keen to resolve so he can be the secretary for that issue (if
that's ok Vincent). So I think the flow becomes
- everyone pushes issues they want resolved into JIRA
- we prioritize a short list to work on in a particular week (or
whatever), we can use votes or just decide amongst ourselves

with that short list we:
- pick the issue at hand
- burst of discussion on the list
- secretary captures the salient points
- offers up the document for review
- go back to discussion/capture/review until complete
- a final document then accompanies the resolution and the issue is closed

If that seems reasonable I can create a little doc for this :-)

jesse

>
with that short list we:

- pick the issue at hand
- burst of discussion on the list
- secretary captures the salient points
- offers up the document for review
- go back to discussion/capture/review until complete
- a final document then accompanies the resolution and the issue is closed

looks good to me, I like itcan even setup a custom workflow in jira so
that issues that are marked 'open for discusion' are the ones that spam
weekly reminders to the email list

jesse

Emmanuel Venisse wrote:

Jason van Zyl a :
>Hi,
>>
>late I think many issues are coming up on the lists and we're not
>dealing with resolving them effectively because, as is natural, people
>have different priorities or are generally just thinking about
>different things that may be interesting or pressing.
>>
>The three things of late I can think of is the development process
>thread, the integration testing thread, and a discussion of best
>practices which fell by the way side a month ago. So I intentionally
>picked up Brett's start at codifying the dev process so that at least
>two of us are on the same page and try and use that momentum to draw
>other people into the discussion. I talked to a couple of subversion
>developers (thanks to Garrett Rooney and Paul Querna), read Pragmatic
>Version Control, talked to Jesse and Brett and found what useful links
>I could find. I put it all together here:
>>
>

I'm totally agree with this doc.
Just a little comment about it: in several place, we have "svn copy" and
mvn release:prepare release:perform". Do you consider them as two
possible actions? because release prepare already do the copy.

You're right, I will correct that. I was cribbing some doco and didn't
even notice. Good eye.

>>
>After this I think we should deal with the integration test issues,
>and then I'd like to work through the best practices listed in the wiki:
>>
>
>>
>>
>I'm not sure what would work best in terms of keeping the threads of
>thought visible when they pass out of the current thread on the
>mailing list but here's my idea based on notions in David Allen's
>"Getting Things Done" which is a fairly practical way of working
>through a series of issues. It basically boils down to collecting all
>issues that are important, putting those notions somewhere safe and
>then prioritizing them so they can be worked on. This is a little
>different where it's not an individual but a group of people but we
>can use JIRA to collect the issues and maybe the devs can vote to try
>and give some priority to the list.

I like the idea to use jira for summarize issues. We can use it for
little comment, but the dev list is better for big issue discussion,
we'll can put in issue the link of mail thread.

I agree, I would leave this up to the secretary for the issue at hand to
transfer the discussion to the wiki.

>>
>the priority is set then as a group we work through the issues
>and try to work through them one to three issues at a time and stick
>with them until we have a resolution. What I would like is a way for
>anyone interested to be able to pick up immediately and help. I'm all
>open to ideas but I don't think we're dealing effectively with our own
>issues because we have no locus to work because the email list is too
>hard to keep track of for a lot of people.
>>
>Maybe something other then JIRA would work but we need to collect,
>store safely, prioritize the short list of issues and anyone who wants
>to see where we are in resolving those issues should be able to see in
>a few minutes where we are. I think it would be easy enough to setup a
>JIRA project and try it. If it doesn't work then we'll look for
>something else. I know this type of setup definitely helps me for
>issues tracked at the Maven TLP level:
>>
>
>>
>Any thoughts?
>>
>At any rate I think the short list now is:
>>
>1. Dev process
>2. Integration Testing
>3. Prioritize best practices and start picking them off

agree.

>>
>course anyone is free to modify this list before a decision is made
>on priority. Just trying to get the ball rolling, and hopefully keep
>it rolling.
>>

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

Brett Porter wrote:
My thoughts:
- I agree with Vincent that JIRA is no good for discussions.

+1

JIRA sucks for conversations.
- I agree with Jesse that the mailing list is still the most natural
medium (people can discuss in their own time, catch up, and get
automatic notification of new comments)
- I agree with Jason that they are getting lost

So, we should combine our technologies:
- discussion starts on dev@maven
- poster decides it requires further discussion (most likely the
original poster, possibly at same time as posting). Adds the issue to
JIRA, under MNG (or relevant project, eg CNTINUUM, or MPA if it is the
dev process), component = design where necessary, target version where
appropriate (eg a Maven 2.1 design discussion)
- when discussion reaches a suitable point (may start this way), a
proposal is put on the wiki
- discussion is regularly used to update the wiki page.
- if discussion goes in circles and no agreement is being reached
because its hard to communicate given the time lag on email, a breakout
on IRC is arranged, logged, summarised and posted to the list, with the
wiki updated. Further discussion may ensue.

The creation of a JIRA item and the relevant wiki page requires that an
issue needs a champion. This should be the original poster, but others
can agree to do that, and anyone can update the wiki or JIRA if they
feel that is appropriate. The champion does not have to be a committer -
anyone can propose and follow through on design discussions.

I think we agree entirely as our posts are very similar. The one thing I
think is different though is that I feel that even if one person starts
the discussion it needs to be picked up by anyone who has the
to finish it. I think what happened with
the dev process works just fine. The issue was in JIRA with me assigned,
but you had time to post some initial thoughts and I tried to follow up
with a document. The issue needs a champion but anyone should be able to
carry it to completion because all the information should be clearly
visible.
- Brett

Jason van Zyl wrote:
>Hi,
>>
>late I think many issues are coming up on the lists and we're not
>dealing with resolving them effectively because, as is natural, people
>have different priorities or are generally just thinking about different
>things that may be interesting or pressing.
>>

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

Jesse McConnell wrote:
>with that short list we:
>>
>- pick the issue at hand
>- burst of discussion on the list
>- secretary captures the salient points
>- offers up the document for review
>- go back to discussion/capture/review until complete
>- a final document then accompanies the resolution and the issue is closed

looks good to me, I like itcan even setup a custom workflow in jira so
that issues that are marked 'open for discusion' are the ones that spam
weekly reminders to the email list

Cool, I've never done a custom workflow in JIRA so I wouldn't mind some
help with that.

I think what we're going to end up here is a good model for any project
and if we can hook in the tools to help automate much of the tedious
work it will rock. I just don't want to get to tied into JIRA. I really
want that issue management API! :-)

jesse

Brett Porter wrote:
Jason van Zyl wrote:
>I think we agree entirely as our posts are very similar. The one thing I
>think is different though is that I feel that even if one person starts
>the discussion it needs to be picked up by anyone who has the
>to finish it. I think what happened with
>the dev process works just fine. The issue was in JIRA with me assigned,
>but you had time to post some initial thoughts and I tried to follow up
>with a document. The issue needs a champion but anyone should be able to
>carry it to completion because all the information should be clearly
>visible.

We agree on that too. Actually, once its in JIRA, it doesn't need a
champion. I was just making sure it didn't get buried, but
responsibility for momentum can be carried by anyone able to at any
given time.

Cool, I'll sift out all the salient bits and push it into wiki. Then
folks can peruse it again and we'll move on from there.
- Brett

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

the holy grail will be meshing with a revision control system so that
releasing of functionalities can be done without having to directly interact
with revision X and revision Ybut I guess we can't solve all of the
issues all at once, have to save something for later

jesse

1/3/06, Jason van Zyl <jason (AT) maven (DOT) orgwrote:

Jesse McConnell wrote:
>with that short list we:
>>
>- pick the issue at hand
>- burst of discussion on the list
>- secretary captures the salient points
>- offers up the document for review
>- go back to discussion/capture/review until complete
>- a final document then accompanies the resolution and the issue is
closed
>
>
>
looks good to me, I like itcan even setup a custom workflow in jira
so
that issues that are marked 'open for discusion' are the ones that spam
weekly reminders to the email list

Cool, I've never done a custom workflow in JIRA so I wouldn't mind some
help with that.

I think what we're going to end up here is a good model for any project
and if we can hook in the tools to help automate much of the tedious
work it will rock. I just don't want to get to tied into JIRA. I really
want that issue management API! :-)
--
jesse