incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Phipps <si...@webmink.com>
Subject Re: Making mailing lists useful (was Re: [Proposal])
Date Thu, 11 Aug 2011 22:19:11 GMT
2011/8/11 J├╝rgen Schmidt <jogischmidt@googlemail.com>

> On Thu, Aug 11, 2011 at 12:21 AM, Simon Phipps <simon@webmink.com> wrote:
>
> >
> > On 10 Aug 2011, at 23:12, Rob Weir wrote:
> >
> > > On Wed, Aug 10, 2011 at 5:28 PM, Kay Schenk <kay.schenk@gmail.com>
> > wrote:
> > >> On Mon, Aug 8, 2011 at 9:01 AM, Ross Gardler <
> > rgardler@opendirective.com>wrote:
> > >>
> > >>> On 8 August 2011 16:14, Kay Schenk <kay.schenk@gmail.com> wrote:
> > >>>
> > >>> ...
> > >>>
> > >>>> From my perspective, I don't see the one BIG list as bad, but it
> would
> > be
> > >>>> VERY helpful if folks could label messages more succinctly and
> > restrict
> > >>>> discussion to rather specific aspects.
> > >>>
> > >>> +1
> > >>>
> > >>> Not to mention useful subject lines (take a look at what the original
> > >>> subject was for the thread I took this from - I didn't edit the
> > >>> original and it is not truncated)
> > >>>
> > >>>> And, documenting what's been discussed is CRITICAL! It is madness
to
> > try
> > >>> to
> > >>>> sift through these messages to get to the "implementable" aspects.
> > >>>
> > >>> +1
> > >>>
> > >>> I really like the practice I see in some communities where someone
> > >>> will take long rambling threads and post a "[summary] foo bar" mail
> > >>> the the thread periodically. This is brilliant for those needing to
> > >>> catch up and also acts as a description of "impementable" conclusions
> > >>> and community consensus that is emerging.
> > >>>
> > >>> Ross
> > >>>
> > >>
> > >> Great idea if we could find a volunteer! I tried to do this (only
> once)
> > on
> > >> the "refactoring discussion" but I'll tell you some of these
> discussions
> > are
> > >> SO lengthy it's impossible.
> > >>
> > >> Maybe we'll do better (and some good soul will step up for the
> > documentation
> > >> aspects) if we can adhere to some discussion standards.
> > >>
> > >
> > > We have a mailing lists page:
> > > http://incubator.apache.org/openofficeorg/mailing-lists.html
> > >
> > > A list of proposed subject tags would fit very well there, after the
> > > first paragraph.   Committers can easily edit this using the Apache
> > > CMS in their browsers:
> > >
> > > http://incubator.apache.org/openofficeorg/docs/edit-cms.html
> > >
> > > For example, I just added the link the email tips earlier today.
> >
> > It would be better to put the list of subject tags on the community wiki
> so
> > that those of us who've not been invited to be committers can also edit
> it.
> >
>
> where is the problem here, if you want to be a committer you know the rules
> and can follow them. I don't see a real problem if you contribute valuable
> content to the project. If you should have a problem with the iCLA then it
> is your problem.
>

I'm not sure this is an appropriate topic to discuss here, but that strong
comment begs a one-time response. Apart from the big, atypical, unmetered
sign-up at the start of the project (in which I did not participate as I
have too much respect for the term "committer" at Apache to want to get the
role that way), the only way I am aware of to become one is to be invited by
the PPMC. I've made a variety of contributions to this Apache project since
it was proposed and they speak for themselves. As for the ICLA, I have not
commented on it, I am not sure what you're implying and I suggest you avoid
further accusations.


> And by the way new tags will or should  be discussed here anyway and
> probably some of the committers will add new approved tags quite fast.
>

Maybe. But I see no reason why this list needs the protection of being on a
controlled access page and would suggest doing so is what needs justifying.
I have not seen a reasoned counter to my proposal for it to be on the
community wiki, so will probably create such a page soon (unless someone
else wants to).

S.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message