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?
Regards,
Dave
Regards, Dave
-----Original Message----- From: N�ir�n Plunkett
[mailto:noi...@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<apa...@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
