[xwiki-devs] [Proposal] XWiki Days for the 6.x cycle
Hi devs, We’ve done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We’ve first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we’re very close to succeed for the last 1600 days (ie 4.4 years)! :) I’d like to congratulate everyone on this achievement which is really awesome. I don’t know a lot of other projects who’ve had this kind of success so we can be proud of ourselves! Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Note that there are still 357 opened bugs which were created since the beginning of the project. My feeling is that it’s hard to keep the sustained pace we’ve set on the BFD days and I think we need a bit of fresh air. Also now that we’ve caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we’re about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success. So what I’m proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity Here’s a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ): A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting? The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above. So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we’ve done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others. I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc. WDYT? Any other proposal or better idea? Thanks -Vincent
On Thu, Jan 30, 2014 at 11:20 AM, vincent@massol.net <vincent@massol.net>wrote:
Hi devs,
We've done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We've first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we're very close to succeed for the last 1600 days (ie 4.4 years)! :)
I'd like to congratulate everyone on this achievement which is really awesome. I don't know a lot of other projects who've had this kind of success so we can be proud of ourselves!
Congrats to everyone. It is most fun to participate in BFDs and cleaning issues gives you a 'clean' feeling :)
Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
Note that there are still 357 opened bugs which were created since the beginning of the project.
My feeling is that it's hard to keep the sustained pace we've set on the BFD days and I think we need a bit of fresh air.
Also now that we've caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we're about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I'm proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here's a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
G.1) Improvements issues closing day G.2) Bug reporting day :) G.3) Pull requests closing day G.4) e.x.o cleaning day (marking old extensions as deprecated, writing documentation, specifying what version the extension is working on, etc. ) Thanks, Caty
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we've done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi Caty On 30 Jan 2014 at 10:38:24, Ecaterina Moraru (Valica) (valicac@gmail.com(mailto:valicac@gmail.com)) wrote:
On Thu, Jan 30, 2014 at 11:20 AM, vincent@massol.net wrote:
Hi devs,
We've done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We've first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we're very close to succeed for the last 1600 days (ie 4.4 years)! :)
I'd like to congratulate everyone on this achievement which is really awesome. I don't know a lot of other projects who've had this kind of success so we can be proud of ourselves!
Congrats to everyone. It is most fun to participate in BFDs and cleaning issues gives you a 'clean' feeling :)
Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
Note that there are still 357 opened bugs which were created since the beginning of the project.
My feeling is that it's hard to keep the sustained pace we've set on the BFD days and I think we need a bit of fresh air.
Also now that we've caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we're about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I'm proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here's a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
G.1) Improvements issues closing day
Indeed I meant to add this one and forgot. It’s an interesting one!
G.2) Bug reporting day :)
Not sure I understand this one… Whenever someone sees a bug he reports it…
G.3) Pull requests closing day
Yes, good one too.
G.4) e.x.o cleaning day (marking old extensions as deprecated, writing documentation, specifying what version the extension is working on, etc. )
This one could be part of the Documentation Fixing Day IMO. Thanks -Vincent
Thanks, Caty
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we've done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
On Thu, Jan 30, 2014 at 10:40 AM, vincent@massol.net <vincent@massol.net> wrote:
Hi Caty
On 30 Jan 2014 at 10:38:24, Ecaterina Moraru (Valica) (valicac@gmail.com(mailto:valicac@gmail.com)) wrote:
On Thu, Jan 30, 2014 at 11:20 AM, vincent@massol.net wrote:
Hi devs,
We've done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We've first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we're very close to succeed for the last 1600 days (ie 4.4 years)! :)
I'd like to congratulate everyone on this achievement which is really awesome. I don't know a lot of other projects who've had this kind of success so we can be proud of ourselves!
Congrats to everyone. It is most fun to participate in BFDs and cleaning issues gives you a 'clean' feeling :)
Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
Note that there are still 357 opened bugs which were created since the beginning of the project.
My feeling is that it's hard to keep the sustained pace we've set on the BFD days and I think we need a bit of fresh air.
Also now that we've caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we're about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I'm proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here's a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
G.1) Improvements issues closing day
Indeed I meant to add this one and forgot. It's an interesting one!
G.2) Bug reporting day :)
Not sure I understand this one... Whenever someone sees a bug he reports it...
G.3) Pull requests closing day
Yes, good one too.
G.4) e.x.o cleaning day (marking old extensions as deprecated, writing documentation, specifying what version the extension is working on, etc. )
This one could be part of the Documentation Fixing Day IMO.
I agree, for me "Documentation Fixing Day" is more or less a xwiki.org day.
Thanks -Vincent
Thanks, Caty
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we've done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, First of all, congrats to everyone. It would be great if we have a "Testing day" and a "Localization day", because, for example, in Romanian the localization is not really great. Andreea On Thu, Jan 30, 2014 at 11:20 AM, vincent@massol.net <vincent@massol.net>wrote:
Hi devs,
We've done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We've first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we're very close to succeed for the last 1600 days (ie 4.4 years)! :)
I'd like to congratulate everyone on this achievement which is really awesome. I don't know a lot of other projects who've had this kind of success so we can be proud of ourselves!
Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
Note that there are still 357 opened bugs which were created since the beginning of the project.
My feeling is that it's hard to keep the sustained pace we've set on the BFD days and I think we need a bit of fresh air.
Also now that we've caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we're about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I'm proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here's a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we've done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi Andreea, On 30 Jan 2014 at 10:46:56, Andreea Popescu (andreea.popescu@xwiki.com(mailto:andreea.popescu@xwiki.com)) wrote:
Hi,
First of all, congrats to everyone.
It would be great if we have a "Testing day" and a "Localization day", because, for example, in Romanian the localization is not really great.
A Localization Improvement Day is a very good idea IMO :) I’m less thrilled by the testing day which for me is something that needs to be done all the time anyway. Not sure what we would on that day that we don’t do normally. There’s E) though (Code Coverage Day) which is close to this one but in a more interesting way IMO since the tests we write stay and don’t need to be done again and again manually. Ok let’s continue brainstorming on days and since we have a lot we’ll then decide which ones we want to do and when! :) Thanks -Vincent
Andreea
On Thu, Jan 30, 2014 at 11:20 AM, vincent@massol.net wrote:
Hi devs,
We've done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We've first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we're very close to succeed for the last 1600 days (ie 4.4 years)! :)
I'd like to congratulate everyone on this achievement which is really awesome. I don't know a lot of other projects who've had this kind of success so we can be proud of ourselves!
Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
Note that there are still 357 opened bugs which were created since the beginning of the project.
My feeling is that it's hard to keep the sustained pace we've set on the BFD days and I think we need a bit of fresh air.
Also now that we've caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we're about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I'm proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here's a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we've done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+1 localization day but as a l10n.xwiki.org say in general (improve the wiki itself too) On Thu, Jan 30, 2014 at 10:51 AM, vincent@massol.net <vincent@massol.net> wrote:
Hi Andreea,
On 30 Jan 2014 at 10:46:56, Andreea Popescu (andreea.popescu@xwiki.com(mailto:andreea.popescu@xwiki.com)) wrote:
Hi,
First of all, congrats to everyone.
It would be great if we have a "Testing day" and a "Localization day", because, for example, in Romanian the localization is not really great.
A Localization Improvement Day is a very good idea IMO :)
I'm less thrilled by the testing day which for me is something that needs to be done all the time anyway. Not sure what we would on that day that we don't do normally. There's E) though (Code Coverage Day) which is close to this one but in a more interesting way IMO since the tests we write stay and don't need to be done again and again manually.
Ok let's continue brainstorming on days and since we have a lot we'll then decide which ones we want to do and when! :)
Thanks -Vincent
Andreea
On Thu, Jan 30, 2014 at 11:20 AM, vincent@massol.net wrote:
Hi devs,
We've done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We've first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we're very close to succeed for the last 1600 days (ie 4.4 years)! :)
I'd like to congratulate everyone on this achievement which is really awesome. I don't know a lot of other projects who've had this kind of success so we can be proud of ourselves!
Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
Note that there are still 357 opened bugs which were created since the beginning of the project.
My feeling is that it's hard to keep the sustained pace we've set on the BFD days and I think we need a bit of fresh air.
Also now that we've caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we're about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I'm proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here's a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we've done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Thu, Jan 30, 2014 at 11:08 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
+1 localization day but as a l10n.xwiki.org say in general (improve the wiki itself too)
s/say/day/
On Thu, Jan 30, 2014 at 10:51 AM, vincent@massol.net <vincent@massol.net> wrote:
Hi Andreea,
On 30 Jan 2014 at 10:46:56, Andreea Popescu (andreea.popescu@xwiki.com(mailto:andreea.popescu@xwiki.com)) wrote:
Hi,
First of all, congrats to everyone.
It would be great if we have a "Testing day" and a "Localization day", because, for example, in Romanian the localization is not really great.
A Localization Improvement Day is a very good idea IMO :)
I'm less thrilled by the testing day which for me is something that needs to be done all the time anyway. Not sure what we would on that day that we don't do normally. There's E) though (Code Coverage Day) which is close to this one but in a more interesting way IMO since the tests we write stay and don't need to be done again and again manually.
Ok let's continue brainstorming on days and since we have a lot we'll then decide which ones we want to do and when! :)
Thanks -Vincent
Andreea
On Thu, Jan 30, 2014 at 11:20 AM, vincent@massol.net wrote:
Hi devs,
We've done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We've first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we're very close to succeed for the last 1600 days (ie 4.4 years)! :)
I'd like to congratulate everyone on this achievement which is really awesome. I don't know a lot of other projects who've had this kind of success so we can be proud of ourselves!
Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
Note that there are still 357 opened bugs which were created since the beginning of the project.
My feeling is that it's hard to keep the sustained pace we've set on the BFD days and I think we need a bit of fresh air.
Also now that we've caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we're about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I'm proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here's a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we've done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
Hi,
Note that there are still 357 opened bugs which were created since the beginning of the project.
I guess the trouble with the remaining bugs is that they are the hard ones that cannot be fixed in a single day. It looks more like something like a dedicated "bug crunching week" for that would be necessary; at last they seem to need a similar attention as new features might need.
My feeling is that it’s hard to keep the sustained pace we’ve set on the BFD days and I think we need a bit of fresh air.
Also now that we’ve caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we’re about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I’m proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here’s a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
On 01/30/2014 10:37 AM, Ecaterina Moraru (Valica) wrote:
G.1) Improvements issues closing day
I agree this would be important, too. Especially with user interfaces often a "small" improvement helps a lot improving user experience.
G.4) e.x.o cleaning day (marking old extensions as deprecated, writing documentation, specifying what version the extension is working on, etc. )
On 01/30/2014 10:40 AM, vincent@massol.net wrote:
This one could be part of the Documentation Fixing Day IMO.
Unless if one finds out that an extension does not longer work and instead of making it as deprecated just fixes it. I feel allocation some time to keep extensions up to date and running would be a good thing, because: * most people who start developing code for XWiki start with getting some extension / code snippet etc. and tweak the a little * the code they see there are thus the one that gives them the first impression "how to do things" - if that is outdated code e.g. using deprecated API, this will cause that kind of "old" code to spread around in the user base * if at least some selected part is marked as "up to date" this also gives users who install extensions a better impression about XWiki in general * and aside of that, unlike fixing core bugs, updating extensions is something that even I feel I can do without having my head spin too much. ;) The only downside I see with that is that folks might prefer to update code, however remotely useful, to update the documentation ;) Just for that reason it maybe might be better to distinguish between "xwiki.org Doc fixing" and "extensions cleaning" day.
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we’ve done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
See below On 30 Jan 2014 at 14:57:48, Clemens Klein-Robbenhaar (c.robbenhaar@espresto.com(mailto:c.robbenhaar@espresto.com)) wrote:
Hi,
Note that there are still 357 opened bugs which were created since the beginning of the project.
I guess the trouble with the remaining bugs is that they are the hard ones that cannot be fixed in a single day. It looks more like something like a dedicated "bug crunching week" for that would be necessary; at last they seem to need a similar attention as new features might need.
My feeling is that it’s hard to keep the sustained pace we’ve set on the BFD days and I think we need a bit of fresh air.
Also now that we’ve caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we’re about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I’m proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here’s a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
On 01/30/2014 10:37 AM, Ecaterina Moraru (Valica) wrote:
G.1) Improvements issues closing day
I agree this would be important, too. Especially with user interfaces often a "small" improvement helps a lot improving user experience.
G.4) e.x.o cleaning day (marking old extensions as deprecated, writing documentation, specifying what version the extension is working on, etc. )
On 01/30/2014 10:40 AM, vincent@massol.net wrote:
This one could be part of the Documentation Fixing Day IMO.
Unless if one finds out that an extension does not longer work and instead of making it as deprecated just fixes it. I feel allocation some time to keep extensions up to date and running would be a good thing, because: * most people who start developing code for XWiki start with getting some extension / code snippet etc. and tweak the a little * the code they see there are thus the one that gives them the first impression "how to do things" - if that is outdated code e.g. using deprecated API, this will cause that kind of "old" code to spread around in the user base * if at least some selected part is marked as "up to date" this also gives users who install extensions a better impression about XWiki in general * and aside of that, unlike fixing core bugs, updating extensions is something that even I feel I can do without having my head spin too much. ;)
The only downside I see with that is that folks might prefer to update code, however remotely useful, to update the documentation ;) Just for that reason it maybe might be better to distinguish between "xwiki.org Doc fixing" and "extensions cleaning" day.
I’m not against it, it’s just that I don’t see what there would be to do and I don’t think there’s enough for everyone. At best you can run this once and it’s over in half a day. Personally I’m doing this almost every day already… Or do you mean that this day would be about *testing* all extensions and grade them as working/not working/etc? If so we would need the ratings system in place on e.x.o first IMO because we’ll need some way to record what we find. So you’d need to specify more precisely what this day would be made of I think. Thanks -Vincent
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we’ve done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On 01/30/2014 03:08 PM, vincent@massol.net wrote: [...]
On 01/30/2014 10:37 AM, Ecaterina Moraru (Valica) wrote:
G.1) Improvements issues closing day
I agree this would be important, too. Especially with user interfaces often a "small" improvement helps a lot improving user experience.
G.4) e.x.o cleaning day (marking old extensions as deprecated, writing documentation, specifying what version the extension is working on, etc. )
On 01/30/2014 10:40 AM, vincent@massol.net wrote:
This one could be part of the Documentation Fixing Day IMO.
Unless if one finds out that an extension does not longer work and instead of making it as deprecated just fixes it. I feel allocation some time to keep extensions up to date and running would be a good thing, because: * most people who start developing code for XWiki start with getting some extension / code snippet etc. and tweak the a little * the code they see there are thus the one that gives them the first impression "how to do things" - if that is outdated code e.g. using deprecated API, this will cause that kind of "old" code to spread around in the user base * if at least some selected part is marked as "up to date" this also gives users who install extensions a better impression about XWiki in general * and aside of that, unlike fixing core bugs, updating extensions is something that even I feel I can do without having my head spin too much. ;)
The only downside I see with that is that folks might prefer to update code, however remotely useful, to update the documentation ;) Just for that reason it maybe might be better to distinguish between "xwiki.org Doc fixing" and "extensions cleaning" day.
I’m not against it, it’s just that I don’t see what there would be to do and I don’t think there’s enough for everyone. At best you can run this once and it’s over in half a day. Personally I’m doing this almost every day already…
Or do you mean that this day would be about *testing* all extensions and grade them as working/not working/etc? If so we would need the ratings system in place on e.x.o first IMO because we’ll need some way to record what we find.
So you’d need to specify more precisely what this day would be made of I think.
Second one. Yes, I meant about testing and updating the extensions itself. Of course this will not apply to each and every extension that someone ever uploaded and then walked away. Figuring out the "right" extensions by rational criteria would be tricky; maybe an approach based on personal likes might still produce usable results (i.e. "attractive" extensions will be maintained). Instead of a rating system (i.e. how good does the extension work at all) I rather meant a compatibility label to tell that the extension does not longer work with version x.y Also I felt it is more constructive to fix a broken extension (assuming it only broke because of some compatibility issues), and label it as "works with version x.y" instead of just testing it and label it as "broken with x.y"
Thanks -Vincent
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we’ve done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
On 30 Jan 2014 at 15:49:56, Clemens Klein-Robbenhaar (c.robbenhaar@espresto.com(mailto:c.robbenhaar@espresto.com)) wrote:
On 01/30/2014 03:08 PM, vincent@massol.net wrote:
[...]
On 01/30/2014 10:37 AM, Ecaterina Moraru (Valica) wrote:
G.1) Improvements issues closing day
I agree this would be important, too. Especially with user interfaces often a "small" improvement helps a lot improving user experience.
G.4) e.x.o cleaning day (marking old extensions as deprecated, writing documentation, specifying what version the extension is working on, etc. )
On 01/30/2014 10:40 AM, vincent@massol.net wrote:
This one could be part of the Documentation Fixing Day IMO.
Unless if one finds out that an extension does not longer work and instead of making it as deprecated just fixes it. I feel allocation some time to keep extensions up to date and running would be a good thing, because: * most people who start developing code for XWiki start with getting some extension / code snippet etc. and tweak the a little * the code they see there are thus the one that gives them the first impression "how to do things" - if that is outdated code e.g. using deprecated API, this will cause that kind of "old" code to spread around in the user base * if at least some selected part is marked as "up to date" this also gives users who install extensions a better impression about XWiki in general * and aside of that, unlike fixing core bugs, updating extensions is something that even I feel I can do without having my head spin too much. ;)
The only downside I see with that is that folks might prefer to update code, however remotely useful, to update the documentation ;) Just for that reason it maybe might be better to distinguish between "xwiki.org Doc fixing" and "extensions cleaning" day.
I’m not against it, it’s just that I don’t see what there would be to do and I don’t think there’s enough for everyone. At best you can run this once and it’s over in half a day. Personally I’m doing this almost every day already…
Or do you mean that this day would be about *testing* all extensions and grade them as working/not working/etc? If so we would need the ratings system in place on e.x.o first IMO because we’ll need some way to record what we find.
So you’d need to specify more precisely what this day would be made of I think.
Second one. Yes, I meant about testing and updating the extensions itself. Of course this will not apply to each and every extension that someone ever uploaded and then walked away. Figuring out the "right" extensions by rational criteria would be tricky; maybe an approach based on personal likes might still produce usable results (i.e. "attractive" extensions will be maintained).
Instead of a rating system (i.e. how good does the extension work at all) I rather meant a compatibility label to tell that the extension does not longer work with version x.y Also I felt it is more constructive to fix a broken extension (assuming it only broke because of some compatibility issues), and label it as "works with version x.y" instead of just testing it and label it as "broken with x.y”
I don’t really agree that it’s up to the xwiki committers to fix bad contributor’s mistakes… We have better things to do with our time. I’d prefer to NOT have this day and instead rely on the community to rate extensions (crowdsourcing). Obviously extensions that don’t work will be rated badly thus dropping to the bottom of the pile and newcomers won’t install them… Thanks -Vincent
Thanks -Vincent
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we’ve done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
An "Upgrade day"? Since every new version give us new possibilities to develop, new best practices, I suppose there is some old code that can be upgrade? 2 examples to make it clear: - Replace all the '$msg' with '$services.localization' [grep -R '\$\<msg\>' xwiki-platform/] - Change all workspaces things into the new '$services.wiki' thing It may concern the core or the extensions. And I suppose that for some, it's a very automatic thing to do (sometime, a script may do the thing exhaustively, the upgrade day will be the day when we write this script! ). -- Jean On jeu., 2014-01-30 at 10:20 +0100, vincent@massol.net wrote:
Hi devs,
We’ve done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We’ve first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we’re very close to succeed for the last 1600 days (ie 4.4 years)! :)
I’d like to congratulate everyone on this achievement which is really awesome. I don’t know a lot of other projects who’ve had this kind of success so we can be proud of ourselves!
Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
Note that there are still 357 opened bugs which were created since the beginning of the project.
My feeling is that it’s hard to keep the sustained pace we’ve set on the BFD days and I think we need a bit of fresh air.
Also now that we’ve caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we’re about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I’m proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here’s a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we’ve done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
That's " B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy" for me On Fri, Jan 31, 2014 at 11:12 AM, Jean SIMARD <jean.simard@xwiki.com> wrote:
An "Upgrade day"?
Since every new version give us new possibilities to develop, new best practices, I suppose there is some old code that can be upgrade?
2 examples to make it clear: - Replace all the '$msg' with '$services.localization' [grep -R '\$\<msg\>' xwiki-platform/] - Change all workspaces things into the new '$services.wiki' thing
It may concern the core or the extensions. And I suppose that for some, it's a very automatic thing to do (sometime, a script may do the thing exhaustively, the upgrade day will be the day when we write this script! ).
-- Jean
On jeu., 2014-01-30 at 10:20 +0100, vincent@massol.net wrote:
Hi devs,
We've done one year of BFD on the 5.x cycle and this has allowed us to reach a greater goal: one of having caught up with the number of open bugs. We've first succeeded in closing more bugs than there has been created bugs over a year, then over 2 years, then over 3 years, then over 4 years and we're very close to succeed for the last 1600 days (ie 4.4 years)! :)
I'd like to congratulate everyone on this achievement which is really awesome. I don't know a lot of other projects who've had this kind of success so we can be proud of ourselves!
Current result can be seen at: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
Note that there are still 357 opened bugs which were created since the beginning of the project.
My feeling is that it's hard to keep the sustained pace we've set on the BFD days and I think we need a bit of fresh air.
Also now that we've caught up with bugs I believe the most important part is to just try to contain the bug ratio so that we're about even in term of number of new bugs vs umber of bugs we close. If we can achieve this it would already be a very nice success.
So what I'm proposing for the 6.x cycle is this: - one week out of 2 we continue doing a BFD - the other week we do a rolling XWiki Day on another activity
Here's a list of other activities we could do (first mentioned in this thread: http://markmail.org/message/a5ew5ilbgxvf67lu ):
A) Doc Fixing Day: improve xwiki.org B) Deprecation Fixing Day: reduce # of deprecated calls and move code to legacy C) Violation Fixing Dy: reduce # of violations. 12K right now on platform for ex (see http://sonar.xwiki.org/drilldown/issues/org.xwiki.platform:xwiki-platform) D) Javadoc Improvement Day: Add missing javadocs in our code and remove checkstyle excludes E) Code Coverage Day: Add as many tests as possible (unit and functional) to increase the TPC F) Broken Links Day: fix as many broken links as possible on xwiki.org. To find them is easy: we just need to enable the IRC Link Checker botlet and wait on IRC to get them listed! G) Others you would consider interesting?
The only constraint for defining a day is that it contains small elements that can be fixed quickly which is the case for the proposals listed above.
So what I propose to be precise: - one week out of 2 we do a BFD - the other week we do one of each (A through F). Then once we've done a full round we decide which ones are the best for the project, which ones we want to drop and which ones we want to repeat more often than others.
I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we start doing A, then BFD, then B, etc.
WDYT? Any other proposal or better idea?
Thanks -Vincent
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (6)
-
Andreea Popescu -
Clemens Klein-Robbenhaar -
Ecaterina Moraru (Valica) -
Jean SIMARD -
Thomas Mortagne -
vincent＠massol.net