On Mon, Jan 9, 2012 at 9:58 AM, sebb <seb...@gmail.com> wrote:
> On 9 January 2012 14:42, Gary Gregory <garydgreg...@gmail.com> wrote:
>> I think the whole formality of project state should be replaced with a
>> live activity widget like can be seen on other sites. Commit activity
>> and such. If someone were thinking of contributing to a project, the
>> incentive would be removed or seriously diminished by a dead/sleepy
>> project state.
>
> I think the activity widget could be counter-productive.
>
> Component activity tends to go in phases; there may be several weeks
> with no activity and then a flurry.
> Also commits are only a small part of the health of a component.
>
> Activity monitors can work well for frequently occuring activities,
> but component health is much more complicated.
>
> To take a simple example, try measuring committer productivity by SVN commits.
> Some committers commit large chunks, some commit per file; and that
> may vary for a committer.
> Some commits are not "productive" - e.g. whitespace fixes, reverts of
> a bad commit.
> Some commits represent lots of investigation and skill, some may be
> much simpler.
The idea for me is to get a heartbeat representation, not hard
numbers; something that can be automatically generated. If we do
decide to change the state of a component, it should be a more serious
step. A project can look asleep and be fine IMO, ready to go again.
IMO a project should be alive or dead, all this formality for
in-between states ("dormant" and whatnot) is not helpful. As soon as
someone commits, it's not dormant, and I should not have to officially
wake up (with a vote?) a commons project before committing to it IMO.
Project states, if wanted, should be on the Wiki in a list, "this is
how we feel about projects, but a committer can still commit and do
work"
2c,
Gary
>
>> Gary
>>
>> On Jan 9, 2012, at 6:59, Christian Grobmeier <grobme...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> Jelly did not see any activity for nearly two years:
>>> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fjelly
>>>
>>> Last release was in 01.2010.
>>>
>>> We had already discussion on a process to move proper components into
>>> another state, be it "dormant" or "inactive". I would like to
>>> resurrect this discussion. We have had a lots of discussion in the
>>> past: somebody wanted to progress with somehting, like graduating
>>> graph or using Java 5 in a component and the response sometimes was we
>>> have to less man power at Commons.
>>>
>>> Therefore I think we need to tell the people for which components they
>>> can expect releases and for which ones not. Otherwise outsiders may
>>> look at a huge bunch of components and see only little activity.
>>> Wouldn't it be better instead to show only a handful components which
>>> are actively developed?
>>>
>>> Looking at Jelly, it is orphaned. No releases, no releases to be
>>> expected. I would like to move it to dormant or to a new transition
>>> state, if people wish so, maybe called "orphaned" or "inactive" or
>>> whatever.
>>>
>>> What are your thoughts?
>>>
>>> Cheers
>>> Christian
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
