[FM Discuss] credits

[Julian Oliver]

..on or around Sun, Jan 13, 2008 at 08:50:04PM +0100, adam hyde said:
> hey,
> 
> On Sun, 2008-01-13 at 19:47 +0100, Derek Holzer wrote:
> > Hi all,
> > 
> > I think this way of crediting seems most appropriate for most of the 
> > cases. I agree with Julian that if 90% of the material was written by 
> > myself (for example), then the credits should reflect that. And most of 
> > the time, one person has set out the structure and feel of the manual at 
> > the very least, with others filling in whatever gaps are left. When we 
> > have a really and truly collectively-written manual, we could revisit 
> > this issue, of course.
> > 
> 
> The Audacity manual is the best example of a collaboratively written
> manual in FM with chapters contributed by myself, Anthony Oetzmann, and
> Adam Willetts. 
> 
> For me, I am quite happy being credited as a collaborator for this
> manual, and the manuals where I am the main writer (eg. MuSE). So
> increasingly, I think maybe its a matter of the main contributors (where
> this can be identified) deciding what they prefer. 
> 
> However I would really like to underline the collaborative nature of
> production. If a manual, for example, is mainly written by one person
> then there maybe many others that come across the work and wish to clean
> up layout, spell check, contribute chapters, tweak etc. We should be
> careful to leave the door open to these people so they are also
> motivated to contribute. My worry about crediting explicitly one person
> as the 'writer' is fine and deserved in many cases (such as Blender),
> but it might not necessarily communicate well that anyone can contribute
> and hence may deter contributions.


another thought, how about making this communication explicitly clear in
that case?

in the credits section of the book, put the text:

"Make your contribution to the next version of this manual. see
 http://flossmanuals.com/contribute for more information.."

cheers,

-- 
http://julianoliver.com
http://selectparks.net

messages containing HTML will not be read.