incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [www][wiki] Web, Wiki, and Participation (was RE: Making mailing lists useful ...)
Date Fri, 12 Aug 2011 19:01:28 GMT

On Aug 12, 2011, at 11:16 AM, Rob Weir wrote:

> On Fri, Aug 12, 2011 at 1:25 PM, Dave Fisher <dave2wave@comcast.net> 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.
>> 
> 
> I like that idea.  A "sandbox" where anyone can enter markdown and get
> a preview, but not commit the changes.  Then allow easy generation of
> a patch.
> 
> But I think that is still most appropriate for "core" pages.
> 
> Like many other unresolved threads on this list, we're still churning
> on how we distinguish:
> 
> 1) Core website pages which should only be directly edited by Committers
> 
> and
> 
> 2) Additional pages which are considered to be part of the project's
> current or potential documentation set, and which must be under Apache
> 2.0 or compatible license
> 
> and
> 
> 3) Subsidiary "community" pages which should be editable by everyone,
> regardless of license
> 
> 
> OOo was #3, but for all content.  This worked, but only because the
> project maintained an army of volunteers to keep the website and wiki
> in a reasonable shape.  The typical Apache website is more #1.  iCLA,
> required. Army, optional.
> 
> It is possible that #1 and #2 are the same thing in the end.  I don't
> know.  But I think it is useful to think of these 3 categories, and
> realize that in the end, not everything is going to end up in a single
> bucket.    For example, there are parts of the existing OOo wiki that
> cannot be moved to #1 or #2.  They have incompatible or indeterminable
> licenses.
> 
> The technical challenge, as I see it, is how we can move -- where
> permitted by license -- content among these three categories with the
> least effort.  Allow control where control is needed.  But don't
> enforce top-down control everywhere.  I think this is possible, but
> will be far easier if we're all using the same application.  In other
> words, if we're doing the core website, the core doc and the community
> work all in MediaWiki, then it should be possible to make this work.
> If we do it with a mix of Apache CMS, CWiki and MediaWiki, it might
> also be possible, but with far greater effort.

While I disagree that Apache CMS/MediaWiki integration is a far greater effort, that is certainly
the case for CWiki and MediaWiki.

I certainly see that the CWiki OOOUSER should have its pages moved to the MediaWik once that
is live and then be removed. No hurry though. The OOODEV wiki can go away.

There are features to the Apache CMS that we can use for more "dynamic" content. For instance
if the MediaWiki provides an RSS or Atom feed we can copy the mechanism that www.apache.org
uses to show feeds. See Latest Activity and Latest News on www.apache.org

The additional work is keeping consistent Look & Feel. This work is up front and in html
and css. Now to stop talking about it and do it in the Apache CMS, if we go another way later...

> 
>> 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.

This is an "army" recruitment plan.

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
>>> 
>> 
>> 


Mime
View raw message