[FM Discuss] residency, and floss for $

[adam hyde]

hey

I firstly want to thank everyone for these comments, its helping me a
great deal in shaping the plan. 

> 
> this all sounds like pretty hairy territory to me. the moment you start
> coupling qualitative or contextual evaluations of contributions -
> whether automated or not - with money you're opening up a can of worms. 
> some will question that their contribution is 'worth less' than another's 
> and claim bad/unfair/biased judgement on the part of FM.
> 
> one thing i'd try and avoid, let alone provide a context for, is a basis 
> for volunteers to argue the economic worth of their contributions.

i agree, its sticky ground. The idea for reviewing content would not be
for volunteer contributions ot the manuals in general, but to hold
quarterly Book Bounties. They could work like this:
* FM secures a a sponsor (25,000 euro) - part to fm, part reserved for
paying contributions
* we structure a manual which we identify needs to be written. I was
thinking of a '--with free software' series. eg. Video Editing -- with
free software' or 'Web Development -- with free software' etc
* we do an international call out for contributions and set a deadline
* at that deadline the review process takes place and people are paid
for their contributions

so the idea is to 'throw a rope around' the Book Bounty campaign so it
is specifically about paying contributions for that campaign and
differentiated from the rest of the manuals. a seperate series if you
like


> 
> instead, the value of a contribution should (ideally) be evaluated based
> on the actual work it does in action, ie by the users of that contribution.
> a contribution is only ever as valuable as it is useful.

good point. i entirely agree. 

> 
> some way of publically communicating that value back to the individual 
> contributor would go further than money i think. i don't know how that's
> possible however but some sort of reader-rating system comes to mind.

also a good idea. i have tried that a little here :
http://en.flossmanuals.net/bin/view/OpenOffice/FMComments

however it needs more work, any comments on how to improve this are
appreciated

> 
> it's perhaps worth looking at the fiasco surround Dunc-Tank - a group
> setup to pay select developers to fix bugs and contribute features
> deemed critical to an upcoming release. 
> 
> at the least it's an interesting tale of free-software, motivation and money:
> 
>   http://tieguy.org/blog/2006/06/18/crowding-out-of-intrinsic-motivations-aka-the-bounty-problem/
> 
>   http://www.linux.com/articles/57294
> 

thanks :) i am reading them now over my coffee.

> > 
> > souns like a good clear distinction to me. Perhaps Maintainers get paid
> > (where possible) but also have deadlines etc. This is what I was gettign
> > at with the post about added-value advertising. Each maintainer could
> > take some of the income from the ads for the manual they maintain.
> >
> 
> i agree with you both here. perhaps it is easy enough to establish an
> economically arguable difference between creating and maintaining a
> manual, and contributing to it.


ok, goodo

> > 
> > yep, good idea. In the situation of maintainers being paid the role is
> > clear but should be written down. It would be something like:
> > * structure the manual
> > * ensure chapters reflect current software version
> > * look for new contributers
> > * keep the edit homepage up to date
> > * manage the print-on-demand 
> > * update the published manual as necessary
> > 
> 
> while this looks good, how do you propose dealing with the event of someone
> abusing the opportunity or fail to meet manual quality/content criteria?
> 

its a management issue. i think the judgement has to come on a case by
case basis but the expectations of maintainers should be clearly defined
beforehand

> for instance, if someone were to start 10 new 5 page manuals for some unpopular 
> and/or trivial software and nominate themselves the maintainer, would you 
> reserve the right to _not_ publish their contribution?

we could say the repository (where the manuals are written) can be used
by anyone for the purpose of writing free documentation about free
software. the manuals can, afterall, be output in html or included in a
website with the ajax plugin. 

but...maintainers will only get paid for manuals that are hosted on the
front of the floss manuals website. this allows for a bit of
differentiation and quality control...no?

adam





> julian
> 
-- 


adam hyde
floss manuals

free manuals for free software
http://www.flossmanuals.net

mobile : + 31 6 154 22770 (Netherlands mobile)
email : adam at flossmanuals.net