On 9 January 2012 15:17, Gary Gregory <garydgreg...@gmail.com> wrote:
> 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.
In which case, the measure should not be published externally, as it
has no independent meaning.
Which is one of the objections I have to the widget idea - it can
easily give the wrong impression to outsiders.
> 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.
Again, a single commit is not sufficient to show that a project is active.
Certainly in the past, there have been global commits to all projects,
e.g. to correct a problem with site generation.
> 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"
That's a separate issue from attracting outside contributions.
But I think there are some components that are clearly not going to be
developed further, e.g. because the need for them has gone away.
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
