[FM Discuss] scribn the bazaar

[adam hyde]

cooool.

yes, i think i would be the FM mother-o-saurus if pushed ...hehe...nice
point :)

your point: 
> 
> 
> I think the tools for "ownership" should 
> not be distinct from the tools for "participation"...

is very salient...ponder ponder...

so...what if x group wants to be exclusive 'in' FM. they build a manual
and then actively fend off contributors...

adam


On Tue, 2009-11-17 at 08:53 -0500, Joshua Facemyer wrote:
> On 11/17/2009 06:25 AM, adam hyde wrote:
> > On Sun, 2009-11-15 at 22:10 -0500, Joshua Facemyer wrote:
>  >
> >> Right.  That's what makes it a hard question - because ideally anyone
> >> can contribute, but realistically some contributions/contributors will
> >> be so poor as to destroy the content (or at least derail it) if not
> >> closely monitored.
> >>
> >
> > interesting discussion. i guess i tend to think that there is nothing
> > lost by trying it open first (as we do for fm now) - keeping the pathway
> > open for as many contributions as possible - and then raise the
> > threshold if problems arise (so far I haven't seen any problems arise).
>  >
>  > one very real issue is that we don't yet really have the tools to  assist
>  > this 'variable threshold' since fm is built on the premise that
>  > everything is open.
>  >
>  > im trying to imagine the tools that might enable this...anyone have
>  > thoughts on this? or do we leave this to the culture of the
>  > maintainer/or book contributors to moderate this socially/culturally...
>  >
> 
> 
> My point was that it *should* be open - that ownership and openness can 
> be compatible.  (I think we should make the distinction between 
> effective openness, or encouraging productive participation, and 
> destructive openness, or encouraging all participation, here.)  Even a 
> closely monitored project can be very open.  I think FM does this nicely 
> in many ways (not that things might not be done better - no implications :).
> 
> For example, Adam, you've got a specific set of ideals that you want FM 
> to be, and it's important for the main contributors to participate in 
> those ideals.  If this weren't the case, and you let anyone do whatever 
> they wanted willy-nilly, FM would cease to be as it was intended to be.
> 
> Instead, you encourage participation (also without which, incidentally, 
> FM would cease to be :) but direct the contributors to the original (or 
> modified) goals that will make FM according to the ideals.  But even in 
> that formation of ideals and direction, you have left things open for 
> discussion/change/improvement.  I suspect, however, if someone hijacked 
> FM for a different purpose, you'd defend her like a mother FM-o-saurus. 
>   Or at least you'd try to persuade the hijacker to stop doing bad things.
> 
> So, to bring the point to it's conclusion, FM's ideals are both quality 
> and open participation (both which should inspire the other), and we've 
> already got a good start.
> 
> Jumping off from that point, I think the tools for "ownership" should 
> not be distinct from the tools for "participation", and there should be 
> both social/cultural tools *and* technical tools for these ends.  Of 
> course, the technical tools are mainly in question here, though the 
> discussion can't realistically separate them from each other.
> 
> Personally, I'd like to see (in some form or another):
> 
> Statuses/privileges for users (this doesn't have to be much of a 
> hierarchical thing, just some basic things like the ability to publish, 
> revert changes, etc, for those who are more involved with a manual.  And 
> an override/impeachment process by contributor vote could be built in, 
> if necessary, though ideally there would need be no such thing.)
> 
> Task lists that are tied to chapters/manuals and are assignable.  An 
> aggregation of all pages' tasks for the manual would be nice too.
> 
> Better versioning control for easily seeing changes, comparing and 
> possibly reverting.
> 
> Community discussion pages that can be used to help organize, possibly 
> integrated with a wiki-type documentation structure/markup?
> 
> I know some of these things are in the works and have been discussed. 
> I'm just working things out for the discussion...my temporary conclusion 
> being that we may not need much more than what is already going to 
> happen.  I guess, overall, the idea of maintainers is important, and 
> giving them tools to easily do the things they need to make sure a 
> manual stays on track - both by encouraging participation and seeing 
> that the changes that are made improve quality.
> 
> JF


-- 
Adam Hyde
Founder FLOSS Manuals
German mobile : + 49 177 4935122
Email : adam at flossmanuals.net
irc: irc.freenode.net #flossmanuals

"Free manuals for free software"
http://www.flossmanuals.net/about