separate JIRA project for dev process and design

[Jason van Zyl <ja...@maven.org>]

Hi,

I was just looking over our discussion and without a separate project 
for the dev process and design JIRA doesn't make it very easy to look at 
the popular issues. So it would definitely be easier for reporting to 
have a separate project but it might also be good to separate 
design/process todos vs scheduled work todos.

Any thoughts?

-- 

jvz.

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

Simplex sigillum veri. (Simplicity is the seal of truth.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: separate JIRA project for dev process and design

[Jason van Zyl <ja...@maven.org>]

Brett Porter wrote:
> Jason van Zyl wrote:
>>> For design, I believe it should go with the project itself, targetted at
>>> the same release as it is aimed for.
>> Not sure if all of them would align with a release, but more importantly
>> it's not easy to see the priorities in design vs scheduled work given
>> the way JIRA is. If you can get the popular issues in combination with a
>> filter, say for a design component, then that's cool otherwise it's not
>> easy to see what's up for debate.
> 
> Sorry, I'm unsure of what the difference is. Can you provide an example
> of a design issue that is not also a feature? Or two things that should
> be separately prioritised?

The integration tests would be the first example I could think of. A lot 
of the discussion would revolve around best practices and directory 
layout which don't correspond to any coding that needs to be done. Many 
of the best practices also fall into this category. I just feel it will 
be easier to track design vs work being done, even for the design of 
features that do require coding. To clearly find in one place the 
decisions that were made about the design before the work was started.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> 


-- 

jvz.

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

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

  -- Eric Hoffer, Reflections on the Human Condition

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: separate JIRA project for dev process and design

[Brett Porter <br...@apache.org>]

Jason van Zyl wrote:
>> For design, I believe it should go with the project itself, targetted at
>> the same release as it is aimed for.
> 
> Not sure if all of them would align with a release, but more importantly
> it's not easy to see the priorities in design vs scheduled work given
> the way JIRA is. If you can get the popular issues in combination with a
> filter, say for a design component, then that's cool otherwise it's not
> easy to see what's up for debate.

Sorry, I'm unsure of what the difference is. Can you provide an example
of a design issue that is not also a feature? Or two things that should
be separately prioritised?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: separate JIRA project for dev process and design

[Jason van Zyl <ja...@maven.org>]

Brett Porter wrote:
> Initial thoughts are -1.
> 
> To me, the Maven dev process is a function of the whole project and can
> easily be dealt with in MPA. 

The dev process will be applied to all the projects in the Maven TLP 
yes, but I'm specifically talking about a JIRA project for scheduled 
work like MNG and then another JIRA project for design, say MNGD.

I don't think there'll be a lot of "issues"
> to raise there, especially nothing requiring scheduling.

The issues in something like MNG would be used to schedule work for 
releases in m2. The issues in MNGD would be where we keep track of 
design for m2.

> For design, I believe it should go with the project itself, targetted at
> the same release as it is aimed for.

Not sure if all of them would align with a release, but more importantly 
it's not easy to see the priorities in design vs scheduled work given 
the way JIRA is. If you can get the popular issues in combination with a 
filter, say for a design component, then that's cool otherwise it's not 
easy to see what's up for debate.

> - Brett
> 
> Jason van Zyl wrote:
>> Hi,
>>
>> I was just looking over our discussion and without a separate project
>> for the dev process and design JIRA doesn't make it very easy to look at
>> the popular issues. So it would definitely be easier for reporting to
>> have a separate project but it might also be good to separate
>> design/process todos vs scheduled work todos.
>>
>> Any thoughts?
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> 


-- 
jvz.

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

We know what we are, but know not what we may be.

   -- Shakespeare

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: separate JIRA project for dev process and design

[Brett Porter <br...@apache.org>]

Initial thoughts are -1.

To me, the Maven dev process is a function of the whole project and can
easily be dealt with in MPA. I don't think there'll be a lot of "issues"
to raise there, especially nothing requiring scheduling.

For design, I believe it should go with the project itself, targetted at
the same release as it is aimed for.

- Brett

Jason van Zyl wrote:
> Hi,
> 
> I was just looking over our discussion and without a separate project
> for the dev process and design JIRA doesn't make it very easy to look at
> the popular issues. So it would definitely be easier for reporting to
> have a separate project but it might also be good to separate
> design/process todos vs scheduled work todos.
> 
> Any thoughts?
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org