Opening Issues no matter how trivial the commit/change is.

Coordinator
Jan 27, 2009 at 4:18 AM
Hi Everyone,

I would like to raise a concern about how we are keeping track of the changes that we are doing in NPanday. Lets make it a habit to always include the WorkItemId in the commits and if the change is unrelated to an existing issue just create a new issue no matter how trivial the change maybe.

Please feel free to put in your comments,suggestions or reactions


Thanks,

Joe
Editor
Jan 27, 2009 at 1:20 PM
Hi,

I do agree on adding the workitem but I think your last commit log is a bit too much:

Fix for http://www.codeplex.com/npanday/WorkItem/View.aspx?WorkItemId=9021
Description: Missing framework checks
Resolution: changed to generic File.separator for other running OS.
Affected modules: [components/dotnet-executable/compiler/impl/DefaultCompiler.java]

I think that #issuenumber with the resolution description is really enough (well I think that it is the most we can ask from contributors)

Regards,
Cédric



On Tue, Jan 27, 2009 at 6:18 AM, jocaba <notifications@codeplex.com> wrote:

From: jocaba

Hi Everyone,

I would like to raise a concern about how we are keeping track of the changes that we are doing in NPanday. Lets make it a habit to always include the WorkItemId in the commits and if the change is unrelated to an existing issue just create a new issue no matter how trivial the change maybe.

Please feel free to put in your comments,suggestions or reactions


Thanks,

Joe

Read the full discussion online.

To add a post to this discussion, reply to this email (npanday@discussions.codeplex.com)

To start a new discussion for this project, email npanday@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Editor
Jan 27, 2009 at 1:24 PM
Oh, another related thing could be to add the SCM revision number in the issue tracker comments when closing/fixing.

Cédric,

On Tue, Jan 27, 2009 at 3:20 PM, Mimil Mimil <mimilowns@gmail.com> wrote:
Hi,

I do agree on adding the workitem but I think your last commit log is a bit too much:

Fix for http://www.codeplex.com/npanday/WorkItem/View.aspx?WorkItemId=9021
Description: Missing framework checks
Resolution: changed to generic File.separator for other running OS.
Affected modules: [components/dotnet-executable/compiler/impl/DefaultCompiler.java]

I think that #issuenumber with the resolution description is really enough (well I think that it is the most we can ask from contributors)

Regards,
Cédric




On Tue, Jan 27, 2009 at 6:18 AM, jocaba <notifications@codeplex.com> wrote:

From: jocaba

Hi Everyone,

I would like to raise a concern about how we are keeping track of the changes that we are doing in NPanday. Lets make it a habit to always include the WorkItemId in the commits and if the change is unrelated to an existing issue just create a new issue no matter how trivial the change maybe.

Please feel free to put in your comments,suggestions or reactions


Thanks,

Joe

Read the full discussion online.

To add a post to this discussion, reply to this email (npanday@discussions.codeplex.com)

To start a new discussion for this project, email npanday@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com



Developer
Jan 27, 2009 at 4:32 PM
I like Joe's last commit message, but like Cédric I think it's too much to expect from the volunteer labor force. :)

I'd suggest that we do need an issue opened for non-trivial changes.  If you're just fixing a typo, it's not necessary.  But if you're changing behavior, or doing something important enough that it needs to show up in the release notes, then an issue needs to be opened.

Instead of the url to the issue tracker, just the number should be enough.  Maybe put it in square brackets to make parsing easier later:  [90123]

Some of the recent commits have been hard to figure out -- sometimes the summary of the issue isn't descriptive enough, such as the "Possible bug in ... " one I saw.  As someone who spends time digging in svn history to figure out what happened, I need to know:  What was the problem, and how does this commit fix it?  This also helps potential contributors understand how things work.

Adding the revision number to the issue when closing it is a great idea.

I see there is a Release Guidelines page already... once this is sorted out, maybe someone can add a Development Guidelines page?

Thanks,
--
Wendy
Editor
Jan 28, 2009 at 3:15 PM
Hello,

I think someone (in the npanday team) should take care of reviewing the issues to schedule and prioritize them and take care of the issue lifecycle (Fixed, Closed ...).

Regards,
Cédric,

On Tue, Jan 27, 2009 at 6:34 PM, wsmoak <notifications@codeplex.com> wrote:

From: wsmoak

I like Joe's last commit message, but like Cédric I think it's too much to expect from the volunteer labor force. :)

I'd suggest that we do need an issue opened for non-trivial changes. If you're just fixing a typo, it's not necessary. But if you're changing behavior, or doing something important enough that it needs to show up in the release notes, then an issue needs to be opened.

Instead of the url to the issue tracker, just the number should be enough. Maybe put it in square brackets to make parsing easier later: [90123]

Some of the recent commits have been hard to figure out -- sometimes the summary of the issue isn't descriptive enough, such as the "Possible bug in ... " one I saw. As someone who spends time digging in svn history to figure out what happened, I need to know: What was the problem, and how does this commit fix it? This also helps potential contributors understand how things work.

Adding the revision number to the issue when closing it is a great idea.

I see there is a Release Guidelines page already... once this is sorted out, maybe someone can add a Development Guidelines page?

Thanks,
--
Wendy

Read the full discussion online.

To add a post to this discussion, reply to this email (npanday@discussions.codeplex.com)

To start a new discussion for this project, email npanday@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com