commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: Problems...
Date Sun, 05 Mar 2006 01:56:42 GMT
On 3/4/06, Henri Yandell <flamefew@gmail.com> wrote:
> On 3/4/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> > On 3/3/06, Henri Yandell <flamefew@gmail.com> wrote:
<snip/>
>
> My site issues are information-architecture/design issues - I think
> it's too noisy and big, in many places we don't pay attention to user
> manuals but spend too much space on the basic info and we don't treat
> the documentation properly in releases. The cop-out is to have a site
> per release, but that's ignoring the issue that our sites and
> documentation are intermingled.
>
<snap/>

Makes sense to explore long term solutions. For the short term, what
bit of the documentation do you think we don't treat properly? Some
components have started creating per release doc menus, which we
should encourage for now, as an example, see [digester] or [logging].
Also feel free to add any suggestions to:

http://wiki.apache.org/jakarta-commons/ReleaseChecking

That way we can collectively make sure we're hitting the mark.


> This one is more repeating complaints I've heard from people who
> struggle to get involved with Commons. I do think it's a problem on
> getting people involved - Commons should be the easiest project to get
> involved in as the codebase is very modular and you don't have to
> understand a big huge design. However the mailing list is detrimental
> to the newcomer to open-source, it's not a nice one to make your first
> subscribed mailing list.
>
> No idea on solutions though. Maybe we just acknowledge that newcomers
> to open-source aren't the target audience and focus on committers of
> other projects.
>
<snip/>

Oh well ... thats a tough one, IMO. I think we are quite welcoming to
newcomers or otherwise on these lists, but ofcourse, my opinion
doesn't help if that is the general perception ;-) Some of this goes
back to dormancy as well, posts for dormant components tend to get
little responses, and may lead to puzzlement.


> >
> > Commons or Web Components, as appropriate?
>
> Web Components would be a grouping in a unified Commons/Jakarta :)
>
<snap/>

OK, I see ;-)


> First step - buy a usb key and get PGP setup on my Mac to point to it.
> Some old memories that releasing on Macs was problematic (Java-wise),
> but hopefully that's old news.
>
> Second step - volunteer to do releases. SCXML getting close then?
>
<snip/>

I think so. I got a second opinion from Tim a couple of months back
(its all in the archives), where he pointed to a couple of things that
he thought should be fixed before a release (optimal parsing and
documentation -- see bugzilla tickets on scxml). Fixed the first, user
guide / docs should be in good shape in about a week. Independent
opinions are always welcome.


> > > We've recently raised issues in managing the sandbox promotion/failure cycle.
> > >
> > <snap/>
> >
> > I think we've become increasingly particular about sandbox promotion,
> > and correctly so. I also think we should perhaps cap the sandbox stay
> > for a component, lest it be left at "almost promoted" state forever.
> > That doesn't help anyone.
>
> Current state is that at 6 months old a component gets voted on dormancy.
>
<snap/>

I'm aware of the 6 month SVN inactivity metric (which really works on
lazy consensus, rather than a vote -- but you know that ;-). I was
probably a bit unclear in that part of my last post, I was thinking
more in terms of whether we can / should make an effort in watching
out for "early signs" and avoiding getting into [feedparser] like
situations. SVN dormancy is the effect, there are many causes.

Few others (not comparing to FP) that come to mind in the "almost
released" category (in proper, but not released) are:

 * [resources] Since now it isn't part of Struts 1.3.0, seems thats a
setback to interest in releasing.

 * [vfs] Given the [compress] faux pas, seems we've stalled a release.

We should watch for situations like these, lest it lead to some
frustration down the road. I'd like to help both, currently lacking
cycles.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message