incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [www][wiki] Web, Wiki, and Participation (was RE: Making mailing lists useful ...)
Date Thu, 25 Aug 2011 22:41:40 GMT
On Thu, Aug 25, 2011 at 3:22 PM, Dave Fisher <dave2wave@comcast.net> wrote:

>
> On Aug 25, 2011, at 2:58 PM, Kay Schenk wrote:
>
> >
> >
> > On 08/25/2011 02:56 PM, Dave Fisher wrote:
> >>
> >> On Aug 25, 2011, at 2:31 PM, Kay Schenk wrote:
> >>
> >>> Hi--
> >>>
> >>> I think I deleted  lot of conversations in this thread and that is it a
> bit old, but see below...
> >>>
> >>> On 08/12/2011 10:25 AM, Dave Fisher wrote:
> >>>>
> >>>> On Aug 12, 2011, at 9:30 AM, Dennis E. Hamilton wrote:
> >>>>
> >>>>> +1 on
> >>>>>
> >>>>> " I think the value of opening up that list to a broader range of
> >>>>> contributors is worth the cost of the extra click."
> >>>>>
> >>>>> - Dennis
> >>>>>
> >>>>> In my experience editing a wiki and creating a patch are
> >>>>> qualitatively and quantitatively different.
> >>>>>
> >>>>> Editing a wiki, especially one that is inviting (Media Wiki
> >>>>> qualifies for me, others not so much), provides for discussion and
> >>>>> has an important internet feature: disintermediation.
> >>>>>
> >>>>> The appeal of wikis (and forums too) is that it provides
> >>>>> disintermediation on behalf of non-expert participation.  And it
> >>>>> has immediacy, something we must not undervalue.  You don't get
> >>>>> Wikipedia by a procedure that involves submitting patches. Not
> >>>>> ever.
> >>>>>
> >>>>> I think every approach we assess here should be tested by how it
> >>>>> invites greater participation.  That does not mean we grant
> >>>>> committer status to every bloke who knocks on the door, because
> >>>>> that is about the provenance of the code base and the integrity
of
> >>>>> releases.
> >>>>>
> >>>>> There are amazing activities that benefit from end-user support,
> >>>>> peer support, and developers contributing in visible ways that are
> >>>>> not significant in terms of Apache licensing and issues around
> >>>>> releases.  But developers can provide perspective and transparency
> >>>>> using the community playground too.
> >>>>>
> >>>>> So, for example, the main web site for the project needs to be
> >>>>> non-user-edited for technical as well as policy reasons.  Then one
> >>>>> question would be how little can we have there in order to gain
the
> >>>>> contributions of non-developers/-committers in all of those places
> >>>>> where they can shine -- and perhaps be(come) experts of another
> >>>>> kind through those contributions.
> >>>>>
> >>>>> The proper question, for me, is not how much to have under
> >>>>> committer control and PPMC-intermediation, but how little we can
> >>>>> have without increased ceremony and technical barriers because of
> >>>>> an over-riding consideration.  Very little should trump open,
> >>>>> casual participation.
> >>>>
> >>>> ++++1.
> >>>>
> >>>> On the wiki, a user may or may not have editing rights, but other
> >>>> than that the wiki is designed to allow change.
> >>>>
> >>>> The whole html vs mdtext question that Kay has been raising is all
> >>>> about how to work on the website in a most casual manner with the
> >>>> least amount of "ceremony". One of the key advantages of the Apache
> >>>> CMS is making it easy for Committers to modify content on the fly
> >>>> also makes contribution comparatively more difficult for
> >>>> non-committers. For non-commiters this means installing a whole
> >>>> document build system.
> >>>>
> >>>> One approach could be to modify the Apache CMS web-gui to allow
> >>>> non-committers to browse and make patches. I don't know how hard that
> >>>> would be to do.
> >>>>
> >>>> A search box on the main site can point to google and can search both
> >>>> the main site and the wiki.
> >>>>
> >>>> When we are ready to consider each OOo project site for conversion we
> >>>> should send an email to ooo-dev to determine which way that site
> >>>> should go - CMS or Wiki? We can label the thread with
> >>>> "[www][${project}]". We can also ask for someone to step up and lead
> >>>> the content conversion process for a project.
> >>>
> >>> hmmm...well generally I think this is a very good idea. Should we get
> together a list of the project heads and start this process now?
> >>>
> >>> I might also suggest that by some consensus we put together a lost of
> areas that we absolutely, positively DON'T want on the wiki for control
> reasons. I will happily work on a wiki page with these ideas.
> >>
> >> Will you be editing
> https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-to-ASF-site-recommendation,
or starting a new page?
> >>
> >
> > Well I had actually posted my OWN thoughts on this page (in the last
> column)--
> > https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains
> >
> > However, I could, of course, take out that last column (on the domains
> page) and recreate this whole table on the page you reference above and that
> way we could document findings (based on project lead responses) on the
> OOo-to-ASF-site-recommendation page.
> >
> > Should I do that?
>
> Do what you planned on doing.
>

OK, I think I'll put everything in the doc below somehow... later


> You asked a lot of questions on
> https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-to-ASF-site-recommendation-
do you have answers for some?
>

ha...well yes I do!

- Kay


>
> Regards,
> Dave
>
> >
> >
> >
> >
> >> Regards,
> >> Dave
> >>
> >>>
> >>>>
> >>>> Regards, Dave
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -----Original Message----- From: N�ir�n Plunkett
> >>>>> [mailto:noirin@apache.org] Sent: Friday, August 12, 2011 07:20 To:
> >>>>> ooo-dev@incubator.apache.org Subject: Re: Making mailing lists
> >>>>> useful (was Re: [Proposal])
> >>>>>
> >>>>> On Fri, Aug 12, 2011 at 4:11 PM, Rob Weir<apache@robweir.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> I'm assuming that it is the new list subscriber that benefits
> >>>>>> most from this.  Existing subscribers will just follow the
> >>>>>> conventions they observe being used on the list.  Or do you
> >>>>>> expect to regularly check the wiki to see what new subject tags
> >>>>>> Simon has added?
> >>>>>>
> >>>>>
> >>>>> I think it's highly unlikely that the new list subscriber will
> >>>>> read this in either location; I think the people who are most
> >>>>> likely to read it are those who've been on the list a few days,
see
> >>>>> that there are a few tags floating around, and that the volume of
> >>>>> mail is hectic. (Yes, I know the static page says c. 57/day. I also
> >>>>> know that most people have no concept of what that means as an
> >>>>> addition to their normal mail flow.)
> >>>>>
> >>>>> I expect those people not to be sure what to look for or where,
but
> >>>>> I hope if they've seen a reasonably prominent mention on the static
> >>>>> page saying "This is a high-volume mailing list. Please use clear,
> >>>>> relevant subject lines, and consider using an appropriate tag for
> >>>>> your mail. A list of tags is available at [link].", that they'll
> >>>>> figure it out.
> >>>>>
> >>>>> I think the value of opening up that list to a broader range of
> >>>>> contributors is worth the cost of the extra click.
> >>>>>
> >>>>> Noirin
> >>>>>
> >>>>
> >>>
> >>> --
> >>>
> ------------------------------------------------------------------------
> >>> MzK
> >>>
> >>> "Music expresses that which cannot be said and
> >>> on which it is impossible to be silent."
> >>>                            -- Victor Hugo
> >>
> >
> > --
> > ------------------------------------------------------------------------
> > MzK
> >
> > "Music expresses that which cannot be said and
> > on which it is impossible to be silent."
> >                            -- Victor Hugo
>
>


-- 
---------------------------------------------------------------------------------------
MzK

"Music expresses that which cannot be said and
 on which it is impossible to be silent."
                                                   -- Victor Hugo

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