Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/basic
Cheers, Doru
-- www.tudorgirba.com
"Beauty is where we see it."
good idea
Stef
On Dec 3, 2009, at 12:57 PM, Tudor Girba wrote:
Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/basic
Cheers, Doru
-- www.tudorgirba.com
"Beauty is where we see it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 3 déc. 2009, at 08:57, Tudor Girba wrote:
Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/basic
I was not sure I felt 100% comfortable with that. There are already many things in the bug tracker, some do not feel like bug. For example: 41 Started › [MOOSE] port SCG algorithms to SqMoose simon.denier Todo Feb 2009 Sep 22 4.1 Algos Medium
The wiki pages do not work for this task too, unless someone is willing to do some wiki-gardening.
So I spent some time this morning to play with google code, see if we could have two tabs of issues, one for defects and enhancements, one for project and long-term goals. We cant.
So I spent some more time configuring the issues page, tweaking a few things which annoyed me.
From now on:
1) when you create an issue as a developer, the issue is no longer automatically assigned to you. It is created as 'New' without an owner. If you want/start to tackle an issue, first edit it: - mark it as started - put your name as owner so that we know you are working on that
I added the column 'Reporter' to see who reported the issue. I also spent some times this morning 'unregistering' myself from issue I cant deal with right now. It means there are lots of 'new' issues now if anyone is willing to take them. I suggest you do the same if you dont want we come after you about issue XXX :)
2) I change a bit the type of issues. In particular, I remove Todo and Task which were fuzzy and add Engineering and Project (I also updated the current issues to mirror that).
Basically, Engineering is for any activities related to maintenance, refactoring the source code, enhancing its quality, applying lint rules, conforming to regularities, etc. There is lots to do in this area and unfortunately, no reward.
Project is in particular for what Doru suggests, that is long-term projects you undertake, or even more small tasks which are somehow autonomous from the code base. The wizard if a good example of that.
Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
So next time you enter an issue, *please* take a bit of time to think about the type.
I hope it will help us to get a better picture of what is going on in the Moose dev, and where things should be going.
-- Simon
Nice job, Simon.
Doru
On 3 Dec 2009, at 15:11, Simon Denier wrote:
On 3 déc. 2009, at 08:57, Tudor Girba wrote:
Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/basic
I was not sure I felt 100% comfortable with that. There are already many things in the bug tracker, some do not feel like bug. For example: 41 Started › [MOOSE] port SCG algorithms to SqMoose simon.denier Todo Feb 2009 Sep 22 4.1 Algos Medium
The wiki pages do not work for this task too, unless someone is willing to do some wiki-gardening.
So I spent some time this morning to play with google code, see if we could have two tabs of issues, one for defects and enhancements, one for project and long-term goals. We cant.
So I spent some more time configuring the issues page, tweaking a few things which annoyed me.
From now on:
- when you create an issue as a developer, the issue is no longer
automatically assigned to you. It is created as 'New' without an owner. If you want/start to tackle an issue, first edit it:
- mark it as started
- put your name as owner so that we know you are working on that
I added the column 'Reporter' to see who reported the issue. I also spent some times this morning 'unregistering' myself from issue I cant deal with right now. It means there are lots of 'new' issues now if anyone is willing to take them. I suggest you do the same if you dont want we come after you about issue XXX :)
- I change a bit the type of issues. In particular, I remove Todo
and Task which were fuzzy and add Engineering and Project (I also updated the current issues to mirror that).
Basically, Engineering is for any activities related to maintenance, refactoring the source code, enhancing its quality, applying lint rules, conforming to regularities, etc. There is lots to do in this area and unfortunately, no reward.
Project is in particular for what Doru suggests, that is long-term projects you undertake, or even more small tasks which are somehow autonomous from the code base. The wizard if a good example of that.
Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
So next time you enter an issue, *please* take a bit of time to think about the type.
I hope it will help us to get a better picture of what is going on in the Moose dev, and where things should be going.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
Hi,
I see one problem with the Type-Project: How do you know when you should close it?
For example, now you have a CAnalyzer project, but that is already around. So, CAnalyzer is rather better as a Component tag.
Cheers, Doru
On 3 Dec 2009, at 15:18, Tudor Girba wrote:
Nice job, Simon.
Doru
On 3 Dec 2009, at 15:11, Simon Denier wrote:
On 3 déc. 2009, at 08:57, Tudor Girba wrote:
Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/basic
I was not sure I felt 100% comfortable with that. There are already many things in the bug tracker, some do not feel like bug. For example: 41 Started › [MOOSE] port SCG algorithms to SqMoose simon.denier Todo Feb 2009 Sep 22 4.1 Algos Medium
The wiki pages do not work for this task too, unless someone is willing to do some wiki-gardening.
So I spent some time this morning to play with google code, see if we could have two tabs of issues, one for defects and enhancements, one for project and long-term goals. We cant.
So I spent some more time configuring the issues page, tweaking a few things which annoyed me.
From now on:
- when you create an issue as a developer, the issue is no longer
automatically assigned to you. It is created as 'New' without an owner. If you want/start to tackle an issue, first edit it:
- mark it as started
- put your name as owner so that we know you are working on that
I added the column 'Reporter' to see who reported the issue. I also spent some times this morning 'unregistering' myself from issue I cant deal with right now. It means there are lots of 'new' issues now if anyone is willing to take them. I suggest you do the same if you dont want we come after you about issue XXX :)
- I change a bit the type of issues. In particular, I remove Todo
and Task which were fuzzy and add Engineering and Project (I also updated the current issues to mirror that).
Basically, Engineering is for any activities related to maintenance, refactoring the source code, enhancing its quality, applying lint rules, conforming to regularities, etc. There is lots to do in this area and unfortunately, no reward.
Project is in particular for what Doru suggests, that is long-term projects you undertake, or even more small tasks which are somehow autonomous from the code base. The wizard if a good example of that.
Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
So next time you enter an issue, *please* take a bit of time to think about the type.
I hope it will help us to get a better picture of what is going on in the Moose dev, and where things should be going.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
On 3 déc. 2009, at 12:44, Tudor Girba wrote:
Hi,
I see one problem with the Type-Project: How do you know when you should close it?
That is why I felt uneasy when you ask to add an entry in the first place :) Even an item like that, "port SCG algorithms to SqMoose", it's not so easy to close it, because it requires lots of work, and difficult to circumvent.
I guess I can close CAnalyzer, or put it On Hold, when I know I will not be active on it in the coming weeks/months. I can still reopen it later.
For example, now you have a CAnalyzer project, but that is already around. So, CAnalyzer is rather better as a Component tag.
Cheers, Doru
On 3 Dec 2009, at 15:18, Tudor Girba wrote:
Nice job, Simon.
Doru
On 3 Dec 2009, at 15:11, Simon Denier wrote:
On 3 déc. 2009, at 08:57, Tudor Girba wrote:
Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/basic
I was not sure I felt 100% comfortable with that. There are already many things in the bug tracker, some do not feel like bug. For example: 41 Started › [MOOSE] port SCG algorithms to SqMoose simon.denier Todo Feb 2009 Sep 22 4.1 Algos Medium
The wiki pages do not work for this task too, unless someone is willing to do some wiki-gardening.
So I spent some time this morning to play with google code, see if we could have two tabs of issues, one for defects and enhancements, one for project and long-term goals. We cant.
So I spent some more time configuring the issues page, tweaking a few things which annoyed me.
From now on:
- when you create an issue as a developer, the issue is no longer
automatically assigned to you. It is created as 'New' without an owner. If you want/start to tackle an issue, first edit it:
- mark it as started
- put your name as owner so that we know you are working on that
I added the column 'Reporter' to see who reported the issue. I also spent some times this morning 'unregistering' myself from issue I cant deal with right now. It means there are lots of 'new' issues now if anyone is willing to take them. I suggest you do the same if you dont want we come after you about issue XXX :)
- I change a bit the type of issues. In particular, I remove Todo
and Task which were fuzzy and add Engineering and Project (I also updated the current issues to mirror that).
Basically, Engineering is for any activities related to maintenance, refactoring the source code, enhancing its quality, applying lint rules, conforming to regularities, etc. There is lots to do in this area and unfortunately, no reward.
Project is in particular for what Doru suggests, that is long-term projects you undertake, or even more small tasks which are somehow autonomous from the code base. The wizard if a good example of that.
Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
So next time you enter an issue, *please* take a bit of time to think about the type.
I hope it will help us to get a better picture of what is going on in the Moose dev, and where things should be going.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
On 3 déc. 2009, at 13:12, Simon Denier wrote:
On 3 déc. 2009, at 12:44, Tudor Girba wrote:
Hi,
I see one problem with the Type-Project: How do you know when you should close it?
That is why I felt uneasy when you ask to add an entry in the first place :) Even an item like that, "port SCG algorithms to SqMoose", it's not so easy to close it, because it requires lots of work, and difficult to circumvent.
I guess I can close CAnalyzer, or put it On Hold, when I know I will not be active on it in the coming weeks/months. I can still reopen it later.
Besides I am now in a "high-throughput" mode for both CAnalyzer and Aspix, so it will make much sense to open issues for things I close a few minutes later.
For example, now you have a CAnalyzer project, but that is already around. So, CAnalyzer is rather better as a Component tag.
Cheers, Doru
On 3 Dec 2009, at 15:18, Tudor Girba wrote:
Nice job, Simon.
Doru
On 3 Dec 2009, at 15:11, Simon Denier wrote:
On 3 déc. 2009, at 08:57, Tudor Girba wrote:
Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/basic
I was not sure I felt 100% comfortable with that. There are already many things in the bug tracker, some do not feel like bug. For example: 41 Started › [MOOSE] port SCG algorithms to SqMoose simon.denier Todo Feb 2009 Sep 22 4.1 Algos Medium
The wiki pages do not work for this task too, unless someone is willing to do some wiki-gardening.
So I spent some time this morning to play with google code, see if we could have two tabs of issues, one for defects and enhancements, one for project and long-term goals. We cant.
So I spent some more time configuring the issues page, tweaking a few things which annoyed me.
From now on:
- when you create an issue as a developer, the issue is no
longer automatically assigned to you. It is created as 'New' without an owner. If you want/start to tackle an issue, first edit it:
- mark it as started
- put your name as owner so that we know you are working on that
I added the column 'Reporter' to see who reported the issue. I also spent some times this morning 'unregistering' myself from issue I cant deal with right now. It means there are lots of 'new' issues now if anyone is willing to take them. I suggest you do the same if you dont want we come after you about issue XXX :)
- I change a bit the type of issues. In particular, I remove
Todo and Task which were fuzzy and add Engineering and Project (I also updated the current issues to mirror that).
Basically, Engineering is for any activities related to maintenance, refactoring the source code, enhancing its quality, applying lint rules, conforming to regularities, etc. There is lots to do in this area and unfortunately, no reward.
Project is in particular for what Doru suggests, that is long- term projects you undertake, or even more small tasks which are somehow autonomous from the code base. The wizard if a good example of that.
Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type- Enhancement = Request for enhancement Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
So next time you enter an issue, *please* take a bit of time to think about the type.
I hope it will help us to get a better picture of what is going on in the Moose dev, and where things should be going.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
-- Simon
We have the same problem in pharo so I would really like to get a solution if we find one. Maybe tag entry with project label but have specific taks/bugs.
stef
On Dec 3, 2009, at 5:12 PM, Simon Denier wrote:
On 3 déc. 2009, at 12:44, Tudor Girba wrote:
Hi,
I see one problem with the Type-Project: How do you know when you should close it?
That is why I felt uneasy when you ask to add an entry in the first place :) Even an item like that, "port SCG algorithms to SqMoose", it's not so easy to close it, because it requires lots of work, and difficult to circumvent.
I guess I can close CAnalyzer, or put it On Hold, when I know I will not be active on it in the coming weeks/months. I can still reopen it later.
For example, now you have a CAnalyzer project, but that is already around. So, CAnalyzer is rather better as a Component tag.
Cheers, Doru
On 3 Dec 2009, at 15:18, Tudor Girba wrote:
Nice job, Simon.
Doru
On 3 Dec 2009, at 15:11, Simon Denier wrote:
On 3 déc. 2009, at 08:57, Tudor Girba wrote:
Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/basic
I was not sure I felt 100% comfortable with that. There are already many things in the bug tracker, some do not feel like bug. For example: 41 Started › [MOOSE] port SCG algorithms to SqMoose simon.denier Todo Feb 2009 Sep 22 4.1 Algos Medium
The wiki pages do not work for this task too, unless someone is willing to do some wiki-gardening.
So I spent some time this morning to play with google code, see if we could have two tabs of issues, one for defects and enhancements, one for project and long-term goals. We cant.
So I spent some more time configuring the issues page, tweaking a few things which annoyed me.
From now on:
- when you create an issue as a developer, the issue is no longer automatically assigned to you. It is created as 'New' without an owner.
If you want/start to tackle an issue, first edit it:
- mark it as started
- put your name as owner so that we know you are working on that
I added the column 'Reporter' to see who reported the issue. I also spent some times this morning 'unregistering' myself from issue I cant deal with right now. It means there are lots of 'new' issues now if anyone is willing to take them. I suggest you do the same if you dont want we come after you about issue XXX :)
- I change a bit the type of issues. In particular, I remove Todo and Task which were fuzzy and add Engineering and Project (I also updated the current issues to mirror that).
Basically, Engineering is for any activities related to maintenance, refactoring the source code, enhancing its quality, applying lint rules, conforming to regularities, etc. There is lots to do in this area and unfortunately, no reward.
Project is in particular for what Doru suggests, that is long-term projects you undertake, or even more small tasks which are somehow autonomous from the code base. The wizard if a good example of that.
Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
So next time you enter an issue, *please* take a bit of time to think about the type.
I hope it will help us to get a better picture of what is going on in the Moose dev, and where things should be going.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I think that for any issue it should be clear when it can be closed. Ideally an issue should also be short in duration, but then you risk getting an explosion of issues, mainly because you cannot model dependencies between issues.
So, an issue "Port EyeSee to Pharo" could be Ok, although it is probably too large.
"Aspix: metamodel, importer, and visualizations for aspect-oriented programs" is not so Ok, because ideally it is something ongoing all the time. Instead, we could have "Create Aspix" as an issue, and if many issues start to be related to the project, we add a Component tag.
For CAnalyzer, I created a Component-CAnalyzer tag because I expect more issues will be related to it. So, from now on we can tag those issues.
What do you think?
Cheers, Doru
On 3 Dec 2009, at 17:20, Stéphane Ducasse wrote:
We have the same problem in pharo so I would really like to get a solution if we find one. Maybe tag entry with project label but have specific taks/bugs.
stef
On Dec 3, 2009, at 5:12 PM, Simon Denier wrote:
On 3 déc. 2009, at 12:44, Tudor Girba wrote:
Hi,
I see one problem with the Type-Project: How do you know when you should close it?
That is why I felt uneasy when you ask to add an entry in the first place :) Even an item like that, "port SCG algorithms to SqMoose", it's not so easy to close it, because it requires lots of work, and difficult to circumvent.
I guess I can close CAnalyzer, or put it On Hold, when I know I will not be active on it in the coming weeks/months. I can still reopen it later.
For example, now you have a CAnalyzer project, but that is already around. So, CAnalyzer is rather better as a Component tag.
Cheers, Doru
On 3 Dec 2009, at 15:18, Tudor Girba wrote:
Nice job, Simon.
Doru
On 3 Dec 2009, at 15:11, Simon Denier wrote:
On 3 déc. 2009, at 08:57, Tudor Girba wrote:
Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/ basic
I was not sure I felt 100% comfortable with that. There are already many things in the bug tracker, some do not feel like bug. For example: 41 Started › [MOOSE] port SCG algorithms to SqMoose simon.denier Todo Feb 2009 Sep 22 4.1 Algos Medium
The wiki pages do not work for this task too, unless someone is willing to do some wiki-gardening.
So I spent some time this morning to play with google code, see if we could have two tabs of issues, one for defects and enhancements, one for project and long-term goals. We cant.
So I spent some more time configuring the issues page, tweaking a few things which annoyed me.
From now on:
- when you create an issue as a developer, the issue is no
longer automatically assigned to you. It is created as 'New' without an owner. If you want/start to tackle an issue, first edit it:
- mark it as started
- put your name as owner so that we know you are working on that
I added the column 'Reporter' to see who reported the issue. I also spent some times this morning 'unregistering' myself from issue I cant deal with right now. It means there are lots of 'new' issues now if anyone is willing to take them. I suggest you do the same if you dont want we come after you about issue XXX :)
- I change a bit the type of issues. In particular, I remove
Todo and Task which were fuzzy and add Engineering and Project (I also updated the current issues to mirror that).
Basically, Engineering is for any activities related to maintenance, refactoring the source code, enhancing its quality, applying lint rules, conforming to regularities, etc. There is lots to do in this area and unfortunately, no reward.
Project is in particular for what Doru suggests, that is long- term projects you undertake, or even more small tasks which are somehow autonomous from the code base. The wizard if a good example of that.
Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type- Enhancement = Request for enhancement Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
So next time you enter an issue, *please* take a bit of time to think about the type.
I hope it will help us to get a better picture of what is going on in the Moose dev, and where things should be going.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
One small comment: Aspix is 'just' the metamodel and importer. Visualisation is another project: AspectMaps, implemented in VW, now re-implementing in Pharo, see http://pleiad.cl/aspectmaps . Comments on AspectMaps are always welcome of course.;-)
On 03 Dec 2009, at 13:39, Tudor Girba wrote:
"Aspix: metamodel, importer, and visualizations for aspect-oriented programs" is not so Ok, because ideally it is something ongoing all the time. Instead, we could have "Create Aspix" as an issue, and if many issues start to be related to the project, we add a Component tag.
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
For CAnalyzer, I created a Component-CAnalyzer tag because I expect more issues will be related to it. So, from now on we can tag those issues.
What do you think?
Yeah, it makes sense. Thanks
Alexandre
On 3 déc. 2009, at 13:39, Tudor Girba wrote:
I think that for any issue it should be clear when it can be closed. Ideally an issue should also be short in duration, but then you risk getting an explosion of issues, mainly because you cannot model dependencies between issues.
So, an issue "Port EyeSee to Pharo" could be Ok, although it is probably too large.
"Aspix: metamodel, importer, and visualizations for aspect-oriented programs" is not so Ok, because ideally it is something ongoing all the time. Instead, we could have "Create Aspix" as an issue, and if many issues start to be related to the project, we add a Component tag.
For CAnalyzer, I created a Component-CAnalyzer tag because I expect more issues will be related to it. So, from now on we can tag those issues.
What do you think?
Rethinking a bit about this, I think the tag Project makes sense, but only for those big things we want to do or have done one day but dont have the resource now. So "port eyesee to pharo" is a good example, same with SCG Algos. Another good example would be "Assess Cairo for Mondrian". Once such a project has started, we can close the issue and create a component instead. So I will close the two above issues.
Cheers, Doru
On 3 Dec 2009, at 17:20, Stéphane Ducasse wrote:
We have the same problem in pharo so I would really like to get a solution if we find one. Maybe tag entry with project label but have specific taks/bugs.
stef
On Dec 3, 2009, at 5:12 PM, Simon Denier wrote:
On 3 déc. 2009, at 12:44, Tudor Girba wrote:
Hi,
I see one problem with the Type-Project: How do you know when you should close it?
That is why I felt uneasy when you ask to add an entry in the first place :) Even an item like that, "port SCG algorithms to SqMoose", it's not so easy to close it, because it requires lots of work, and difficult to circumvent.
I guess I can close CAnalyzer, or put it On Hold, when I know I will not be active on it in the coming weeks/months. I can still reopen it later.
For example, now you have a CAnalyzer project, but that is already around. So, CAnalyzer is rather better as a Component tag.
Cheers, Doru
On 3 Dec 2009, at 15:18, Tudor Girba wrote:
Nice job, Simon.
Doru
On 3 Dec 2009, at 15:11, Simon Denier wrote:
On 3 déc. 2009, at 08:57, Tudor Girba wrote:
> Hi, > > I would kindly ask you to place an entry in the issue tracker > before you start working on something (even if it's not a bug): > http://code.google.com/p/moose-technology/issues/list > > Also, when you add an issue, please make sure to tag it at > least with the Component that is affected by it. If you want > to work on it, also assign it to yourself. > > This has the benefit of communicating your intention around > and synchronize with the rest of us. If you want to be up to > date with the changes in the issue tracker, you can subscribe > to the RSS feed: > http://code.google.com/feeds/p/moose-technology/issueupdates/basic
I was not sure I felt 100% comfortable with that. There are already many things in the bug tracker, some do not feel like bug. For example: 41 Started › [MOOSE] port SCG algorithms to SqMoose simon.denier Todo Feb 2009 Sep 22 4.1 Algos Medium
The wiki pages do not work for this task too, unless someone is willing to do some wiki-gardening.
So I spent some time this morning to play with google code, see if we could have two tabs of issues, one for defects and enhancements, one for project and long-term goals. We cant.
So I spent some more time configuring the issues page, tweaking a few things which annoyed me.
From now on:
- when you create an issue as a developer, the issue is no
longer automatically assigned to you. It is created as 'New' without an owner. If you want/start to tackle an issue, first edit it:
- mark it as started
- put your name as owner so that we know you are working on that
I added the column 'Reporter' to see who reported the issue. I also spent some times this morning 'unregistering' myself from issue I cant deal with right now. It means there are lots of 'new' issues now if anyone is willing to take them. I suggest you do the same if you dont want we come after you about issue XXX :)
- I change a bit the type of issues. In particular, I remove
Todo and Task which were fuzzy and add Engineering and Project (I also updated the current issues to mirror that).
Basically, Engineering is for any activities related to maintenance, refactoring the source code, enhancing its quality, applying lint rules, conforming to regularities, etc. There is lots to do in this area and unfortunately, no reward.
Project is in particular for what Doru suggests, that is long- term projects you undertake, or even more small tasks which are somehow autonomous from the code base. The wizard if a good example of that.
Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type- Enhancement = Request for enhancement Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
So next time you enter an issue, *please* take a bit of time to think about the type.
I hope it will help us to get a better picture of what is going on in the Moose dev, and where things should be going.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
On 3 déc. 2009, at 13:20, Stéphane Ducasse wrote:
We have the same problem in pharo so I would really like to get a solution if we find one. Maybe tag entry with project label but have specific taks/bugs.
That's also what I tried to look for this morning in other issue tracker and related (github, launchpad, sourceforge...)
So far I can only see Trac as proposing out of the box such features: - a roadmap for tracking milestones goals/challenges http://trac.edgewall.org/roadmap - 'seachange' which is a kind of enhanced wishlist (with votes...) http://trac.edgewall.org/roadmap
Onto related things, has anyone ever tested a code review service, such as the one of launchpad?
stef
On Dec 3, 2009, at 5:12 PM, Simon Denier wrote:
On 3 déc. 2009, at 12:44, Tudor Girba wrote:
Hi,
I see one problem with the Type-Project: How do you know when you should close it?
That is why I felt uneasy when you ask to add an entry in the first place :) Even an item like that, "port SCG algorithms to SqMoose", it's not so easy to close it, because it requires lots of work, and difficult to circumvent.
I guess I can close CAnalyzer, or put it On Hold, when I know I will not be active on it in the coming weeks/months. I can still reopen it later.
For example, now you have a CAnalyzer project, but that is already around. So, CAnalyzer is rather better as a Component tag.
Cheers, Doru
On 3 Dec 2009, at 15:18, Tudor Girba wrote:
Nice job, Simon.
Doru
On 3 Dec 2009, at 15:11, Simon Denier wrote:
On 3 déc. 2009, at 08:57, Tudor Girba wrote:
Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/ basic
I was not sure I felt 100% comfortable with that. There are already many things in the bug tracker, some do not feel like bug. For example: 41 Started › [MOOSE] port SCG algorithms to SqMoose simon.denier Todo Feb 2009 Sep 22 4.1 Algos Medium
The wiki pages do not work for this task too, unless someone is willing to do some wiki-gardening.
So I spent some time this morning to play with google code, see if we could have two tabs of issues, one for defects and enhancements, one for project and long-term goals. We cant.
So I spent some more time configuring the issues page, tweaking a few things which annoyed me.
From now on:
- when you create an issue as a developer, the issue is no
longer automatically assigned to you. It is created as 'New' without an owner. If you want/start to tackle an issue, first edit it:
- mark it as started
- put your name as owner so that we know you are working on that
I added the column 'Reporter' to see who reported the issue. I also spent some times this morning 'unregistering' myself from issue I cant deal with right now. It means there are lots of 'new' issues now if anyone is willing to take them. I suggest you do the same if you dont want we come after you about issue XXX :)
- I change a bit the type of issues. In particular, I remove
Todo and Task which were fuzzy and add Engineering and Project (I also updated the current issues to mirror that).
Basically, Engineering is for any activities related to maintenance, refactoring the source code, enhancing its quality, applying lint rules, conforming to regularities, etc. There is lots to do in this area and unfortunately, no reward.
Project is in particular for what Doru suggests, that is long- term projects you undertake, or even more small tasks which are somehow autonomous from the code base. The wizard if a good example of that.
Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type- Enhancement = Request for enhancement Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
So next time you enter an issue, *please* take a bit of time to think about the type.
I hope it will help us to get a better picture of what is going on in the Moose dev, and where things should be going.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Thanks simon, it makes sense.
Alexandre
On 3 Dec 2009, at 11:11, Simon Denier wrote:
On 3 déc. 2009, at 08:57, Tudor Girba wrote:
Hi,
I would kindly ask you to place an entry in the issue tracker before you start working on something (even if it's not a bug): http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with the Component that is affected by it. If you want to work on it, also assign it to yourself.
This has the benefit of communicating your intention around and synchronize with the rest of us. If you want to be up to date with the changes in the issue tracker, you can subscribe to the RSS feed: http://code.google.com/feeds/p/moose-technology/issueupdates/basic
I was not sure I felt 100% comfortable with that. There are already many things in the bug tracker, some do not feel like bug. For example: 41 Started › [MOOSE] port SCG algorithms to SqMoose simon.denier Todo Feb 2009 Sep 22 4.1 Algos Medium
The wiki pages do not work for this task too, unless someone is willing to do some wiki-gardening.
So I spent some time this morning to play with google code, see if we could have two tabs of issues, one for defects and enhancements, one for project and long-term goals. We cant.
So I spent some more time configuring the issues page, tweaking a few things which annoyed me.
From now on:
- when you create an issue as a developer, the issue is no longer
automatically assigned to you. It is created as 'New' without an owner. If you want/start to tackle an issue, first edit it:
- mark it as started
- put your name as owner so that we know you are working on that
I added the column 'Reporter' to see who reported the issue. I also spent some times this morning 'unregistering' myself from issue I cant deal with right now. It means there are lots of 'new' issues now if anyone is willing to take them. I suggest you do the same if you dont want we come after you about issue XXX :)
- I change a bit the type of issues. In particular, I remove Todo
and Task which were fuzzy and add Engineering and Project (I also updated the current issues to mirror that).
Basically, Engineering is for any activities related to maintenance, refactoring the source code, enhancing its quality, applying lint rules, conforming to regularities, etc. There is lots to do in this area and unfortunately, no reward.
Project is in particular for what Doru suggests, that is long-term projects you undertake, or even more small tasks which are somehow autonomous from the code base. The wizard if a good example of that.
Type-Engineering = (Re)engineering the code base to enhance its quality Type-Defect = Report of a software defect Type-Enhancement = Request for enhancement Type-Project = Long-term project or autonomous task Type-Review = Request for a code review Type-Other = Some other kind of issue
So next time you enter an issue, *please* take a bit of time to think about the type.
I hope it will help us to get a better picture of what is going on in the Moose dev, and where things should be going.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Johan Fabry -
Simon Denier -
Stéphane Ducasse -
Tudor Girba