The "once a day" system is far too strenous and rigorous and encourages bad code in some ways.
But once a week I feel is a little too easy to acheive.
And worse, multiple releases in a single week don't count for anything, not even a personal score.
So, to counter this, I have two proposed ideas for people who may have different motives:
Weekly Consistency Metric
Instead of requring simply "once a day", the number of days which have releases on them could be represented as a fraction:
1/7
People who are presently doing "once a week" will get at least a 1/7.
And people who are presently doing "once a day" will get 7/7
That way, you can make people set personal goals of consistency, for instance, a personal goal of 3-a-week, which would be the aim to have runs of 3/7. ( That is, they wish to simply be consistent enough to have 3 days which they have releases on, but not exactly 3 releases )
( For instance, 5/7 is an entirely acheivable and respectable goal, people like to take breaks )
That way they're still encouraged to do >1 , but exactly how many they want to do is up to them.
Volume Metric
Some people are fine with doing a flexible any-amount of releases and don't care what days of the week they fall on, and some people may just release 10 releases on one day and still want to have that score count for something.
Too much gameification of that would be bad, hence why I'm saying these are auxilary metrics that may not necessarily be ranked ( or ranked within certain useful thresholds )
These people could have scores represented as weekly tallies ( ie: "15 releases this week" ), but not be forced to release them on any specific day.
The latter of these appeals to me the most, and may appeal to people like @karenetheridge who don't want to be constrained to some daily rigour and don't want to be harshly penalized for releasing more on a single day and less on the rest of the week. ( I mean, if you release a good thing today, and a good thing today an hour later, why does it matter in terms of valuable CPAN metrics that "oh no, you should have held off and released that later, now you'll have to release something ELSE to make up for it" )
The "once a day" system is far too strenous and rigorous and encourages bad code in some ways.
But once a week I feel is a little too easy to acheive.
And worse, multiple releases in a single week don't count for anything, not even a personal score.
So, to counter this, I have two proposed ideas for people who may have different motives:
Weekly Consistency Metric
Instead of requring simply "once a day", the number of days which have releases on them could be represented as a fraction:
1/7
People who are presently doing "once a week" will get at least a 1/7. And people who are presently doing "once a day" will get 7/7
That way, you can make people set personal goals of consistency, for instance, a personal goal of 3-a-week, which would be the aim to have runs of 3/7. ( That is, they wish to simply be consistent enough to have 3 days which they have releases on, but not exactly 3 releases )
( For instance, 5/7 is an entirely acheivable and respectable goal, people like to take breaks )
That way they're still encouraged to do >1 , but exactly how many they want to do is up to them.
Volume Metric
Some people are fine with doing a flexible any-amount of releases and don't care what days of the week they fall on, and some people may just release 10 releases on one day and still want to have that score count for something.
Too much gameification of that would be bad, hence why I'm saying these are auxilary metrics that may not necessarily be ranked ( or ranked within certain useful thresholds )
These people could have scores represented as weekly tallies ( ie: "15 releases this week" ), but not be forced to release them on any specific day.
The latter of these appeals to me the most, and may appeal to people like @karenetheridge who don't want to be constrained to some daily rigour and don't want to be harshly penalized for releasing more on a single day and less on the rest of the week. ( I mean, if you release a good thing today, and a good thing today an hour later, why does it matter in terms of valuable CPAN metrics that "oh no, you should have held off and released that later, now you'll have to release something ELSE to make up for it" )