[Bf-docboard] Bf-docboard Digest, Vol 119, Issue 11

Ivan Paulos Tomé greylica at gmail.com
Thu Jan 15 13:59:55 CET 2015


Hi !

Here is Ivan Paulos T.

Here is my 2 cents.

I know, I know, I'm now located at the
"Obsolete pieces of Blender junkyard of the obsolete wiki writers..."

I'm reading the contents of this discussion, but we have made it in the
past
several times.

I was working on a project called BTSC since 2011,
but so far, I have no financial help to continue, not even a single
word as "Thank you", or "Can we start a real discussion about your project
?".

I'm seeing those discussions as redundant, and it seems to me that the
move to the Sphinx may help with what BTSC was made to be,
but BTSC was made to use Wigit instead. When I was working,
I was setting up a framework, not a simple "another wiki project".

Now I'm working for another company, and the project was frozen in
August 2014. I have nearly financially broken, and I was really trying to
help,
but so far, I have discovered that some friends here (in Brazil) are even
against BTSC.

I was about to say that was for no reason, but the reason was mostly
related to politics and the ego life of disputed 'positions'.

If you're willing to solve the manual problem, you will have to start with
the reference,
but most people are willing a "simple big tutorial", but you will have to
fix the
references prior to everything. This will need time to fix.

In my opinion, the .rst files are good for one thing:
"Extended tooltips that you can download with or without Blender", but a
manual with a didactic line needs to start fixing "References" prior to
work
on the "User Manual", and after, you can 'tesselate' the whole thing.

Another great tip is that in general, writers and translators are
considered
a problem in free software by some coders, and some of them are even
considered a second level people. And they are, in general, forced to
adapt themselves to every situation that the coders decide that they have
to,
without a real 'voice' at the decisions.

Some of them are even talented enough to become good coders, mainly
because for big projects, you will need to understand what 'organization'
means,
but the free software looses a lot of writers everyday, and the
consequences are obvious:

Bad documentation and coders loosing 'faith' in the free software ecosystem.

Sorry for the long e-mail.
Cheers !


2015-01-15 9:00 GMT-02:00 <bf-docboard-request at blender.org>:

> Send Bf-docboard mailing list submissions to
>         bf-docboard at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.blender.org/mailman/listinfo/bf-docboard
> or, via email, send a message with subject or body 'help' to
>         bf-docboard-request at blender.org
>
> You can reach the person managing the list at
>         bf-docboard-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-docboard digest..."
>
>
> Today's Topics:
>
>    1. Re: Being involved In documentation (Abuelo S. B. Chdancer)
>    2. On types of manual we want (Abuelo S. B. Chdancer)
>    3. Re: Being involved In documentation (Campbell Barton)
>    4. Re: Being involved In documentation (Campbell Barton)
>    5. What has been done so far.... (Abuelo S. B. Chdancer)
>    6. Re: What has been done so far.... (Campbell Barton)
>    7. Re: What has been done so far.... (Abuelo S. B. Chdancer)
>    8. Specific plans and discussion of what our manual should be
>       and how to get it (Abuelo S. B. Chdancer)
>    9. Re: Specific plans and discussion of what our manual should
>       be and how to get it (brita)
>   10. Re: Specific plans and discussion of what our manual should
>       be and how to get it (Greg Zaal)
>   11. Re: Being involved In documentation (Pep Ribal)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 14 Jan 2015 13:54:36 +0100
> From: "Abuelo S. B. Chdancer" <playadance at gmail.com>
> Subject: Re: [Bf-docboard] Being involved In documentation
> To: Blender Documentation Project <bf-docboard at blender.org>
> Message-ID:
>         <
> CAFH9JFOq73hQPLjmTjidQwvdgvEY1Pi+7_ofJxzbCHkXc1Pozg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> In reply to Pep Ribal....
>
> Absolutely. The surprise is that some of what you suggest has been done,
> but who would know? There are people who are listed as being in charge of
> bits of the manual, the list is somewhere on some server, I have forgotten
> where.
>
> It is an odd fact that more people want to code than explain the code. This
> has been the case in the computer industry for decades and the lousy level
> of most manuals is the result. My new hard disk drive comes with a manual
> that warns not to connect the drive when the computer is on. How do you
> read this manual? - It's in pdf format on the drive.  (Anyone notice a
> problem with this?)
>
> I will circulate some guidelines for discussion....
>
> On 14 January 2015 at 07:12, Pep Ribal <pepribal at gmail.com> wrote:
>
> >  Hi all,
> >
> > I understand the disappointment that the new documentation system has
> > caused. I also think that it builds a big barrier for the people who want
> > to help with documentation writing. It's true that the wiki made it much
> > more simple to help, but I agree with Campbell that even the simplicity
> of
> > the wiki didn't motivate people enough. And that means that technology
> was
> > not the problem. I think the technology (wiki) was the right one to use,
> > but the project lacked (and still lacks) something more.
> >
> > The key question is: why isn't people motivated? For instance, Blender
> > development has a huge entry barrier, compared to wiki, and even compared
> > to the new reST-SVN system. However, activity is way bigger in
> development
> > than in documentation. One does not expect that a project as big as
> Blender
> > is suffering from a extremely low documentation development pace.
> >
> > I've been working with Blender since many years ago, but I was away from
> > it for a while. Now that I'm back, I see the same eternal problem that
> was
> > present before: documentation is the worst of Blender, by far. And I
> don't
> > see it changing any time soon, unless something is done. And I don't
> think
> > a change in technology is the response (and even less a change that
> raises
> > the entry barrier).
> >
> > Motivation is the key. But how we manage to motivate people to contribute
> > to the docs?
> >
> > I think that some Project Management skills should be poured in. A
> > "project manager" should be appointed. A few key positions should be
> filled
> > (official writers), and an official documentation team should be set up.
> If
> > we have a team of developers, an official team, with a clear coordinator
> > and a clear team of key developers, each one responsible for his module,
> > why not have the same for documenters? That's what the documentation
> > project lacks. There is no official team. So there is not a feeling of
> > "important department".
> >
> > Why do we need an official team? Because there's no more motivating thing
> > than feeling officially part of something. In this case,  the ?official
> > Blender documentation team?. And not only feeling that, but also seeing
> it,
> > for instance, in the appropriate page in Blender website: names and
> > functions of every ?official? member of that team. I think that would
> > attract writers.
> >
> > But it shouldn't only be a list of names in a web page. Being part of the
> > team should offer additional ?privileges?. The more of them we can give,
> > the more motivation writers will have.
> >
> > What should be offered to writers besides credit? I think one of the most
> > important things is attention from the developer responsible for the
> > documented module. This is a crucial part in all this.
> >
> > Perhaps other things could be offered, but as a start, these couple of
> > things would help enough, I think.
> >
> > Regards,
> >
> > Pep.
> >
> > El 14/01/15 a las 08:33, Abuelo S. B. Chdancer escribi?:
> >
> >  Hi to Nkansah Rexford,
> >
> >  A contributor should be able to go to a normal webpage.
> >
> >  Register what he would be interested in doing.
> >
> >  Be contacted by a real human who agrees the task.
> >
> >  The writer should be able to submit using email or a simple web based
> > upload form. For the text.
> >
> >  If approved by an editor or by peer review the more complicated task of
> > adding illustrations can be handle by some method.
> >
> >
> >
> > On 14 January 2015 at 00:47, Nkansah Rexford <nkansahrexford at gmail.com>
> > wrote:
> >
> >> Hello Chdancer,
> >>
> >>  I think you have a point, and its from a user who's got no idea what
> >> those terms are.
> >>
> >>  However, look at it this way too. Trying to explain every single detail
> >> of the steps will require another documentation on its own. "What repo
> >> is?", "How to clone", "What is reST?", svn (what is even version
> control?
> >> duh!), checkout (what am I buying?), pip, requirements.txt and so on.
> >>
> >>  Those are stuffs with detailed documentations on their own found
> >> everywhere on the net. I don't think the getting started page on Blender
> >> should aggregate all these information and present it to anyone who
> >> actually wants to get started (beside's that'll be aggregating
> >> documentations into a documentation).
> >>
> >>  Of course, more flesh can (and likely will) be added to those getting
> >> started pages, but remember not *everything *can be covered or all the
> >> terminologies can be expounded.
> >>
> >>  I think explaining every single thing on that page defeats the whole
> >> idea of 'getting started'. Its not a training course. Its to get you
> >> started, so they're pointers, offering guidance as to how to go about
> it.
> >>
> >>  Therefore, I think as someone who really wants to get started, doing a
> >> bit more googling and reading outside the getting started page should
> make
> >> things happen much easier, for both authors of get started pages and
> also
> >> the 'get-startee' (bad english, but hope you get it)
> >>
> >>  I know its hard to understand pages like that, but I hope it gets
> >> improved to the best possible to bridge the gap between devs and users.
> >>
> >>  rex
> >>
> >> On Tuesday, January 13, 2015, Abuelo S. B. Chdancer <
> playadance at gmail.com>
> >> wrote:
> >>
> >>>  Campbell Barton reminded...
> >>>
> >>>  "While this is subjective, we have had contributions submitted via our
> >>> project page:
> >>>
> >>> https://developer.blender.org/tag/documentation/ "
> >>>
> >>>
> >>> Guys, someone who USES Blender may not know the first thing about
> >>> coding, someone who can write simple prose explaining to another
> person in
> >>> clear language how to DO something artistic may be totally useless
> when it
> >>> comes to installing software or plugging in a USB plug.
> >>>
> >>>  I bet a lot of possible contributors give up when they read this....
> >>>
> >>>  "We have migrated the content over to reST format, so that the manual
> >>> can be built with Sphinx. A good amount of work is still required to
> >>> complete the migration (learn more about the open tasks in
> Phabricator).
> >>>
> >>> If you want to start contributing or want to have a look at the new
> >>> manual, here we have some instructions.
> >>> How to build the docs locally
> >>>
> >>>    - Checkout the Subversion repository svn checkout
> >>>    https://svn.blender.org/svnroot/bf-manual/trunk
> >>>    - Move to the location where the repo was cloned
> >>>    - Run pip install -r requirements.txt (Windows user make sure you
> >>>    are using Python 2.7, not 3.x)
> >>>    - Build a section of the manual (for example make render)
> >>>    - Launch the contents_quicky.html inside of the html folder and
> >>>    browse the freshly build render docs
> >>>
> >>>
> >>>  That is a hundred times worse than trying to  use the wiki manual. It
> >>> is mindboggingly offputting and not just incomprehensible but presents
> such
> >>> a hurdle that most people will stop at that point and forget being
> involved.
> >>>
> >>>  What it should say is.....
> >>>
> >>>  Read this (hopefully well written and elegantly presented) webpage
> >>> which explains how you register what you would like to do.
> >>>
> >>>  If worried about 'no nothings' writing drivel, that is why we invented
> >>> human editors. Also it is technically possible to have peer reviews of
> >>> submitted entries prior to making the entry official.
> >>>
> >>>  I was in the middle of working on my latest animation.....
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> +Rexford <http://google.com/+Nkansahrexford> | Africa Center
> >> <http://africacenter.net> | WiR
> >> <https://outreach.wikimedia.org/wiki/Wikipedian_in_Residence> |
> >> WikiAfrica <http://wikiafrica.net> | User:Nkansahrexford
> >> <http://en.wikipedia.org/wiki/User:Nkansahrexford>
> >>
> >>
> >> _______________________________________________
> >> Bf-docboard mailing list
> >> Bf-docboard at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-docboard
> >>
> >>
> >
> >
> > _______________________________________________
> > Bf-docboard mailing listBf-docboard at blender.orghttp://
> lists.blender.org/mailman/listinfo/bf-docboard
> >
> >
> >
> > _______________________________________________
> > Bf-docboard mailing list
> > Bf-docboard at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-docboard
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-docboard/attachments/20150114/d0d81c48/attachment.html
>
> ------------------------------
>
> Message: 2
> Date: Wed, 14 Jan 2015 14:05:03 +0100
> From: "Abuelo S. B. Chdancer" <playadance at gmail.com>
> Subject: [Bf-docboard] On types of manual we want
> To: Blender Documentation Project <Bf-docboard at blender.org>
> Message-ID:
>         <
> CAFH9JFPXkSx8z0EZkQpqzqqvoBr_4RaGgtwL1_VvDApzsMUwXQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Please let me know which of these types of manual appeal, or give examples
> of on-line manuals that you have used for other software that you think are
> high quality manuals, or what ideas you have about how a manual should be
> (NOT what software version it runs on or what device it should be
> compatible with)
>
> Do you want a quick reference to remind how to use a command?
>
> Do you want a simple English explanation of not just what it does but why
> you use it?
>
> Do you want a topic based manual - what things can be done, which commands
> are relevant.
>
> Do you want a teaching manual - (tutorials)
>
> Please voice what you want from a manual, because if you don't you'll get a
> massive glob of goo.
>
> Also - what manual or source do you normally turn to  when hitting a
> problem with Blender.
>
> Also- what did you use to learn Blender?
>
> Also - what were (are) the biggest hurdles in learning Blender
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-docboard/attachments/20150114/4b3dd31d/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Thu, 15 Jan 2015 00:19:15 +1100
> From: Campbell Barton <ideasman42 at gmail.com>
> Subject: Re: [Bf-docboard] Being involved In documentation
> To: Blender Documentation Project <bf-docboard at blender.org>
> Message-ID:
>         <CAEcf3NyyVZoiorLgiPR7OZQeq7srtor5C-DOz=
> FeTu-H-kcOAA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Jan 14, 2015 at 5:12 PM, Pep Ribal <pepribal at gmail.com> wrote:
> > Hi all,
> >
> > I understand the disappointment that the new documentation system has
> > caused. I also think that it builds a big barrier for the people who
> want to
> > help with documentation writing. It's true that the wiki made it much
> more
> > simple to help, but I agree with Campbell that even the simplicity of the
> > wiki didn't motivate people enough. And that means that technology was
> not
> > the problem. I think the technology (wiki) was the right one to use, but
> the
> > project lacked (and still lacks) something more.
>
> Yes, its quite possible that the issue we face is todo with getting
> active contributors, no matter which technology we use.
>
> > The key question is: why isn't people motivated? For instance, Blender
> > development has a huge entry barrier, compared to wiki, and even
> compared to
> > the new reST-SVN system. However, activity is way bigger in development
> than
> > in documentation. One does not expect that a project as big as Blender is
> > suffering from a extremely low documentation development pace.
>
> Mailed on this topic a while back,
> http://lists.blender.org/pipermail/bf-docboard/2014-May/004459.html
>
>
> > I've been working with Blender since many years ago, but I was away from
> it
> > for a while. Now that I'm back, I see the same eternal problem that was
> > present before: documentation is the worst of Blender, by far. And I
> don't
> > see it changing any time soon, unless something is done. And I don't
> think a
> > change in technology is the response (and even less a change that raises
> the
> > entry barrier).
> >
> > Motivation is the key. But how we manage to motivate people to
> contribute to
> > the docs?
> >
> > I think that some Project Management skills should be poured in. A
> "project
> > manager" should be appointed. A few key positions should be filled
> (official
> > writers), and an official documentation team should be set up. If we
> have a
> > team of developers, an official team, with a clear coordinator and a
> clear
> > team of key developers, each one responsible for his module, why not have
> > the same for documenters? That's what the documentation project lacks.
> There
> > is no official team. So there is not a feeling of "important department".
>
> Agree, but we need someone who is naturally good in the role of
> helping people work together, not just someone who comes in and says
> they will tell others what to do.
>
> > Why do we need an official team? Because there's no more motivating thing
> > than feeling officially part of something. In this case,  the ?official
> > Blender documentation team?. And not only feeling that, but also seeing
> it,
> > for instance, in the appropriate page in Blender website: names and
> > functions of every ?official? member of that team. I think that would
> > attract writers.
> >
> > But it shouldn't only be a list of names in a web page. Being part of the
> > team should offer additional ?privileges?. The more of them we can give,
> the
> > more motivation writers will have.
> >
> > What should be offered to writers besides credit? I think one of the most
> > important things is attention from the developer responsible for the
> > documented module. This is a crucial part in all this.
>
> Agree connecting writers with devs is important, ideally having new
> features in blender be documented in so devs & writers collaborate.
>
> > Perhaps other things could be offered, but as a start, these couple of
> > things would help enough, I think.
> >
> > Regards,
> >
> > Pep.
> >
> > El 14/01/15 a las 08:33, Abuelo S. B. Chdancer escribi?:
> >
> > Hi to Nkansah Rexford,
> >
> > A contributor should be able to go to a normal webpage.
> >
> > Register what he would be interested in doing.
> >
> > Be contacted by a real human who agrees the task.
> >
> > The writer should be able to submit using email or a simple web based
> upload
> > form. For the text.
> >
> > If approved by an editor or by peer review the more complicated task of
> > adding illustrations can be handle by some method.
> >
> >
> >
> > On 14 January 2015 at 00:47, Nkansah Rexford <nkansahrexford at gmail.com>
> > wrote:
> >>
> >> Hello Chdancer,
> >>
> >> I think you have a point, and its from a user who's got no idea what
> those
> >> terms are.
> >>
> >> However, look at it this way too. Trying to explain every single detail
> of
> >> the steps will require another documentation on its own. "What repo
> is?",
> >> "How to clone", "What is reST?", svn (what is even version control?
> duh!),
> >> checkout (what am I buying?), pip, requirements.txt and so on.
> >>
> >> Those are stuffs with detailed documentations on their own found
> >> everywhere on the net. I don't think the getting started page on Blender
> >> should aggregate all these information and present it to anyone who
> actually
> >> wants to get started (beside's that'll be aggregating documentations
> into a
> >> documentation).
> >>
> >> Of course, more flesh can (and likely will) be added to those getting
> >> started pages, but remember not everything can be covered or all the
> >> terminologies can be expounded.
> >>
> >> I think explaining every single thing on that page defeats the whole
> idea
> >> of 'getting started'. Its not a training course. Its to get you
> started, so
> >> they're pointers, offering guidance as to how to go about it.
> >>
> >> Therefore, I think as someone who really wants to get started, doing a
> bit
> >> more googling and reading outside the getting started page should make
> >> things happen much easier, for both authors of get started pages and
> also
> >> the 'get-startee' (bad english, but hope you get it)
> >>
> >> I know its hard to understand pages like that, but I hope it gets
> improved
> >> to the best possible to bridge the gap between devs and users.
> >>
> >> rex
> >>
> >> On Tuesday, January 13, 2015, Abuelo S. B. Chdancer <
> playadance at gmail.com>
> >> wrote:
> >>>
> >>> Campbell Barton reminded...
> >>>
> >>> "While this is subjective, we have had contributions submitted via our
> >>> project page:
> >>>
> >>> https://developer.blender.org/tag/documentation/ "
> >>>
> >>>
> >>> Guys, someone who USES Blender may not know the first thing about
> coding,
> >>> someone who can write simple prose explaining to another person in
> clear
> >>> language how to DO something artistic may be totally useless when it
> comes
> >>> to installing software or plugging in a USB plug.
> >>>
> >>> I bet a lot of possible contributors give up when they read this....
> >>>
> >>> "We have migrated the content over to reST format, so that the manual
> can
> >>> be built with Sphinx. A good amount of work is still required to
> complete
> >>> the migration (learn more about the open tasks in Phabricator).
> >>>
> >>> If you want to start contributing or want to have a look at the new
> >>> manual, here we have some instructions.
> >>>
> >>> How to build the docs locally
> >>>
> >>> Checkout the Subversion repository svn checkout
> >>> https://svn.blender.org/svnroot/bf-manual/trunk
> >>> Move to the location where the repo was cloned
> >>> Run pip install -r requirements.txt (Windows user make sure you are
> using
> >>> Python 2.7, not 3.x)
> >>> Build a section of the manual (for example make render)
> >>> Launch the contents_quicky.html inside of the html folder and browse
> the
> >>> freshly build render docs
> >>>
> >>>
> >>> That is a hundred times worse than trying to  use the wiki manual. It
> is
> >>> mindboggingly offputting and not just incomprehensible but presents
> such a
> >>> hurdle that most people will stop at that point and forget being
> involved.
> >>>
> >>> What it should say is.....
> >>>
> >>> Read this (hopefully well written and elegantly presented) webpage
> which
> >>> explains how you register what you would like to do.
> >>>
> >>> If worried about 'no nothings' writing drivel, that is why we invented
> >>> human editors. Also it is technically possible to have peer reviews of
> >>> submitted entries prior to making the entry official.
> >>>
> >>> I was in the middle of working on my latest animation.....
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> +Rexford | Africa Center | WiR | WikiAfrica | User:Nkansahrexford
> >>
> >>
> >> _______________________________________________
> >> Bf-docboard mailing list
> >> Bf-docboard at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-docboard
> >>
> >
> >
> >
> > _______________________________________________
> > Bf-docboard mailing list
> > Bf-docboard at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-docboard
> >
> >
> >
> > _______________________________________________
> > Bf-docboard mailing list
> > Bf-docboard at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-docboard
> >
>
>
>
> --
> - Campbell
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 15 Jan 2015 00:19:20 +1100
> From: Campbell Barton <ideasman42 at gmail.com>
> Subject: Re: [Bf-docboard] Being involved In documentation
> To: Blender Documentation Project <bf-docboard at blender.org>
> Message-ID:
>         <
> CAEcf3Nzbhwi3hsJm8O1SiuMqBuHF_JS2FWkErkLPqREb-9FfLg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Jan 14, 2015 at 11:54 PM, Abuelo S. B. Chdancer
> <playadance at gmail.com> wrote:
> > In reply to Pep Ribal....
> >
> > Absolutely. The surprise is that some of what you suggest has been done,
> but
> > who would know? There are people who are listed as being in charge of
> bits
> > of the manual, the list is somewhere on some server, I have forgotten
> where.
> >
> > It is an odd fact that more people want to code than explain the code.
> This
> > has been the case in the computer industry for decades and the lousy
> level
> > of most manuals is the result. My new hard disk drive comes with a manual
> > that warns not to connect the drive when the computer is on. How do you
> read
> > this manual? - It's in pdf format on the drive.  (Anyone notice a problem
> > with this?)
> >
> > I will circulate some guidelines for discussion....
> >
> > On 14 January 2015 at 07:12, Pep Ribal <pepribal at gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> I understand the disappointment that the new documentation system has
> >> caused. I also think that it builds a big barrier for the people who
> want to
> >> help with documentation writing. It's true that the wiki made it much
> more
> >> simple to help, but I agree with Campbell that even the simplicity of
> the
> >> wiki didn't motivate people enough. And that means that technology was
> not
> >> the problem. I think the technology (wiki) was the right one to use,
> but the
> >> project lacked (and still lacks) something more.
> >>
> >> The key question is: why isn't people motivated? For instance, Blender
> >> development has a huge entry barrier, compared to wiki, and even
> compared to
> >> the new reST-SVN system. However, activity is way bigger in development
> than
> >> in documentation. One does not expect that a project as big as Blender
> is
> >> suffering from a extremely low documentation development pace.
> >>
> >> I've been working with Blender since many years ago, but I was away from
> >> it for a while. Now that I'm back, I see the same eternal problem that
> was
> >> present before: documentation is the worst of Blender, by far. And I
> don't
> >> see it changing any time soon, unless something is done. And I don't
> think a
> >> change in technology is the response (and even less a change that
> raises the
> >> entry barrier).
> >>
> >> Motivation is the key. But how we manage to motivate people to
> contribute
> >> to the docs?
> >>
> >> I think that some Project Management skills should be poured in. A
> >> "project manager" should be appointed. A few key positions should be
> filled
> >> (official writers), and an official documentation team should be set
> up. If
> >> we have a team of developers, an official team, with a clear
> coordinator and
> >> a clear team of key developers, each one responsible for his module,
> why not
> >> have the same for documenters? That's what the documentation project
> lacks.
> >> There is no official team. So there is not a feeling of "important
> >> department".
> >>
> >> Why do we need an official team? Because there's no more motivating
> thing
> >> than feeling officially part of something. In this case,  the ?official
> >> Blender documentation team?. And not only feeling that, but also seeing
> it,
> >> for instance, in the appropriate page in Blender website: names and
> >> functions of every ?official? member of that team. I think that would
> >> attract writers.
> >>
> >> But it shouldn't only be a list of names in a web page. Being part of
> the
> >> team should offer additional ?privileges?. The more of them we can
> give, the
> >> more motivation writers will have.
> >>
> >> What should be offered to writers besides credit? I think one of the
> most
> >> important things is attention from the developer responsible for the
> >> documented module. This is a crucial part in all this.
> >>
> >> Perhaps other things could be offered, but as a start, these couple of
> >> things would help enough, I think.
> >>
> >> Regards,
> >>
> >> Pep.
> >>
> >> El 14/01/15 a las 08:33, Abuelo S. B. Chdancer escribi?:
> >>
> >> Hi to Nkansah Rexford,
> >>
> >> A contributor should be able to go to a normal webpage.
> >>
> >> Register what he would be interested in doing.
> >>
> >> Be contacted by a real human who agrees the task.
> >>
> >> The writer should be able to submit using email or a simple web based
> >> upload form. For the text.
> >>
> >> If approved by an editor or by peer review the more complicated task of
> >> adding illustrations can be handle by some method.
> >>
> >>
> >>
> >> On 14 January 2015 at 00:47, Nkansah Rexford <nkansahrexford at gmail.com>
> >> wrote:
> >>>
> >>> Hello Chdancer,
> >>>
> >>> I think you have a point, and its from a user who's got no idea what
> >>> those terms are.
> >>>
> >>> However, look at it this way too. Trying to explain every single detail
> >>> of the steps will require another documentation on its own. "What repo
> is?",
> >>> "How to clone", "What is reST?", svn (what is even version control?
> duh!),
> >>> checkout (what am I buying?), pip, requirements.txt and so on.
> >>>
> >>> Those are stuffs with detailed documentations on their own found
> >>> everywhere on the net. I don't think the getting started page on
> Blender
> >>> should aggregate all these information and present it to anyone who
> actually
> >>> wants to get started (beside's that'll be aggregating documentations
> into a
> >>> documentation).
> >>>
> >>> Of course, more flesh can (and likely will) be added to those getting
> >>> started pages, but remember not everything can be covered or all the
> >>> terminologies can be expounded.
> >>>
> >>> I think explaining every single thing on that page defeats the whole
> idea
> >>> of 'getting started'. Its not a training course. Its to get you
> started, so
> >>> they're pointers, offering guidance as to how to go about it.
> >>>
> >>> Therefore, I think as someone who really wants to get started, doing a
> >>> bit more googling and reading outside the getting started page should
> make
> >>> things happen much easier, for both authors of get started pages and
> also
> >>> the 'get-startee' (bad english, but hope you get it)
> >>>
> >>> I know its hard to understand pages like that, but I hope it gets
> >>> improved to the best possible to bridge the gap between devs and users.
> >>>
> >>> rex
> >>>
> >>> On Tuesday, January 13, 2015, Abuelo S. B. Chdancer
> >>> <playadance at gmail.com> wrote:
> >>>>
> >>>> Campbell Barton reminded...
> >>>>
> >>>> "While this is subjective, we have had contributions submitted via our
> >>>> project page:
> >>>>
> >>>> https://developer.blender.org/tag/documentation/ "
> >>>>
> >>>>
> >>>> Guys, someone who USES Blender may not know the first thing about
> >>>> coding, someone who can write simple prose explaining to another
> person in
> >>>> clear language how to DO something artistic may be totally useless
> when it
> >>>> comes to installing software or plugging in a USB plug.
> >>>>
> >>>> I bet a lot of possible contributors give up when they read this....
> >>>>
> >>>> "We have migrated the content over to reST format, so that the manual
> >>>> can be built with Sphinx. A good amount of work is still required to
> >>>> complete the migration (learn more about the open tasks in
> Phabricator).
> >>>>
> >>>> If you want to start contributing or want to have a look at the new
> >>>> manual, here we have some instructions.
> >>>>
> >>>> How to build the docs locally
> >>>>
> >>>> Checkout the Subversion repository svn checkout
> >>>> https://svn.blender.org/svnroot/bf-manual/trunk
> >>>> Move to the location where the repo was cloned
> >>>> Run pip install -r requirements.txt (Windows user make sure you are
> >>>> using Python 2.7, not 3.x)
> >>>> Build a section of the manual (for example make render)
> >>>> Launch the contents_quicky.html inside of the html folder and browse
> the
> >>>> freshly build render docs
> >>>>
> >>>>
> >>>> That is a hundred times worse than trying to  use the wiki manual. It
> is
> >>>> mindboggingly offputting and not just incomprehensible but presents
> such a
> >>>> hurdle that most people will stop at that point and forget being
> involved.
> >>>>
> >>>> What it should say is.....
> >>>>
> >>>> Read this (hopefully well written and elegantly presented) webpage
> which
> >>>> explains how you register what you would like to do.
> >>>>
> >>>> If worried about 'no nothings' writing drivel, that is why we invented
> >>>> human editors. Also it is technically possible to have peer reviews of
> >>>> submitted entries prior to making the entry official.
> >>>>
> >>>> I was in the middle of working on my latest animation.....
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> +Rexford | Africa Center | WiR | WikiAfrica | User:Nkansahrexford
> >>>
> >>>
> >>> _______________________________________________
> >>> Bf-docboard mailing list
> >>> Bf-docboard at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-docboard
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> Bf-docboard mailing list
> >> Bf-docboard at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-docboard
> >>
> >>
> >>
> >> _______________________________________________
> >> Bf-docboard mailing list
> >> Bf-docboard at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-docboard
> >>
> >
> >
> > _______________________________________________
> > Bf-docboard mailing list
> > Bf-docboard at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-docboard
> >
>
>
>
> --
> - Campbell
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 14 Jan 2015 14:30:27 +0100
> From: "Abuelo S. B. Chdancer" <playadance at gmail.com>
> Subject: [Bf-docboard] What has been done so far....
> To: Blender Documentation Project <bf-docboard at blender.org>
> Message-ID:
>         <
> CAFH9JFNMK8B2sNV4zV3MdxNnfc028Jnfg7YGz_zCjswzqqYf+g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The technical approach has been to make better the bits that can be made
> better by technology. I saw that the new website has a search box and side
> panel navigation. I vaguely registered that there's some kind of software
> available for editors to get into the website and jiggle around with the
> content in some way. Beyond that I haven't a clue what the tech people are
> talking about.
>
> I think they have probably done an excellent job.
>
> They have done what is in their power to do, and it seems that they have
> copied over lots of the old content as a default because no one has decided
> the basics of
>
> what type of manual we want...
>
> what it should contain and essentially
>
> its very purpose.
> Somewhere far away on a web server there is a list of poeple who may have
> made these decisions, but I am unaware of any of that.
>
> I will circulate a draft soon...
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-docboard/attachments/20150114/8fb3e615/attachment-0001.htm
>
> ------------------------------
>
> Message: 6
> Date: Thu, 15 Jan 2015 00:39:49 +1100
> From: Campbell Barton <ideasman42 at gmail.com>
> Subject: Re: [Bf-docboard] What has been done so far....
> To: Blender Documentation Project <bf-docboard at blender.org>
> Message-ID:
>         <CAEcf3Nzz7VQssKKPzGCx5GhOqN=
> oB3DmJtj808CgFN4UTzyxWA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Jan 15, 2015 at 12:30 AM, Abuelo S. B. Chdancer
> <playadance at gmail.com> wrote:
> > The technical approach has been to make better the bits that can be made
> > better by technology. I saw that the new website has a search box and
> side
> > panel navigation. I vaguely registered that there's some kind of software
> > available for editors to get into the website and jiggle around with the
> > content in some way. Beyond that I haven't a clue what the tech people
> are
> > talking about.
> >
> > I think they have probably done an excellent job.
> >
> > They have done what is in their power to do, and it seems that they have
> > copied over lots of the old content as a default because no one has
> decided
> > the basics of
> >
> > what type of manual we want...
> >
> > what it should contain and essentially
> >
> > its very purpose.
> >
> > Somewhere far away on a web server there is a list of poeple who may have
> > made these decisions, but I am unaware of any of that.
> >
> > I will circulate a draft soon...
>
> Yep, this is a conversation we need to have (sooner then later).
>
> It seems people who are involved in the writing side of making a
> manual are just not very active/vocal.
>
> I mailed the list asking for feedback on writing styles (as in style
> for the actual content) and got no response.
>
> It would be really good if people on this list who are interested to
> be involved as writers would speak up more and try to help get a
> clearer focus for the manual.
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 14 Jan 2015 14:47:21 +0100
> From: "Abuelo S. B. Chdancer" <playadance at gmail.com>
> Subject: Re: [Bf-docboard] What has been done so far....
> To: Blender Documentation Project <bf-docboard at blender.org>
> Message-ID:
>         <CAFH9JFNncHRdpiA665-MxHWP1EcbJp=tJhRJVH18MtJWS=
> X68Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Excellent.
>
> I strongly suspect that they are stunned into silence by mutual
> incomprehension and the widespread feeling that what non-technical people
> think of as the essential basics are what technical people think of as
> 'extras we can add on later', but maybe they are just snoozing after a hard
> day sharpening pencils , who knows. Wait a few minutes and I will put
> forward my first suggestions
>
>
>
>
> On 14 January 2015 at 14:39, Campbell Barton <ideasman42 at gmail.com> wrote:
>
> > On Thu, Jan 15, 2015 at 12:30 AM, Abuelo S. B. Chdancer
> > <playadance at gmail.com> wrote:
> > > The technical approach has been to make better the bits that can be
> made
> > > better by technology. I saw that the new website has a search box and
> > side
> > > panel navigation. I vaguely registered that there's some kind of
> software
> > > available for editors to get into the website and jiggle around with
> the
> > > content in some way. Beyond that I haven't a clue what the tech people
> > are
> > > talking about.
> > >
> > > I think they have probably done an excellent job.
> > >
> > > They have done what is in their power to do, and it seems that they
> have
> > > copied over lots of the old content as a default because no one has
> > decided
> > > the basics of
> > >
> > > what type of manual we want...
> > >
> > > what it should contain and essentially
> > >
> > > its very purpose.
> > >
> > > Somewhere far away on a web server there is a list of poeple who may
> have
> > > made these decisions, but I am unaware of any of that.
> > >
> > > I will circulate a draft soon...
> >
> > Yep, this is a conversation we need to have (sooner then later).
> >
> > It seems people who are involved in the writing side of making a
> > manual are just not very active/vocal.
> >
> > I mailed the list asking for feedback on writing styles (as in style
> > for the actual content) and got no response.
> >
> > It would be really good if people on this list who are interested to
> > be involved as writers would speak up more and try to help get a
> > clearer focus for the manual.
> > _______________________________________________
> > Bf-docboard mailing list
> > Bf-docboard at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-docboard
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-docboard/attachments/20150114/59c9cd59/attachment-0001.htm
>
> ------------------------------
>
> Message: 8
> Date: Wed, 14 Jan 2015 15:12:42 +0100
> From: "Abuelo S. B. Chdancer" <playadance at gmail.com>
> Subject: [Bf-docboard] Specific plans and discussion of what our
>         manual should be and how to get it
> To: Blender Documentation Project <bf-docboard at blender.org>
> Message-ID:
>         <
> CAFH9JFMKjYPT5OyaYgBtMMybjMs0NZTmKvzshbYgQij4W2ys5A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Top level design:
>
> What should a manual be and how do we get one?
>
> 1) Quick reference guide to all commands?
>
> 2) Topic based manual of what you might want to do and how to do it?
>
> 3) A place to learn step by step?
>
> Lower level design:
>
> What is a normal page to look like?
>
> How should one page lead or connect to another? (Has the tech already set
> this?)
>
> What should the overall plan for the entire work be?
>
> Contributors:
>
> Finding that rare combination of someone who intimately knows parts of
> Blender and is willing and able to explain it to someone who doesn't
> understand shouldn't be messed up by also requiring that person to be
> technically proficient and willing to learn new software simply to tell
> their story.
>
> If that software is needed to get the text and pictures into the server -
> let those who use it be *sub-editors* and let the *authors* communicate
> with sub-editors using simple software that everyone already has - email &
> browser.
>
> I would tell other potential contributors that they need to indicate in a
> simple webform what they feel able to help on, and tell them that sending
> in their contribution will be technically similar to posting a comment on a
> website - nothing to download, no programming skills needed.
>
> The various ideas would need to be cut down to practical designs and could
> then be again displayed on webpages for public review.
>
> When the design of the work has been decided which includes details of what
> individual pages should have in common and what should be different the
> minor stylistic decisions can be made about whether writing is to say "You
> can" rather than "It is possible to.."
>
>  We need a few web pages that everyone who downloads blender would be asked
> to review asking them to rate which concepts they think would be useful for
> them in learning or using Blender.
>
> I would do a survey of users to try to understand what they/we need or want
> from documentation.
>
> I would send an email to anyone who downs Blender, about 2 weeks later
> asking them to comment on what causes them problems, on where they look for
> information, on how they are learning. I would read them all to get a feel
> for the problem.
>
>  So I suggest the following:
>
> Those who already have downloaded whatever that stuff is that I couldn't
> even be bothered to read - they should be initially *sub-editors *who can
> receive contributions from other simpler folks like me, that *sub-editor*
> then uses that software stuff to get the data onto the server.
>
> Some web page creating type is needed to set-up the following fairly simple
> webpages that I am suggesting, or something similar where normal
> contributors can register their willingness and their self-claimed level of
> expertise. I would be happy to work with the webpage creator.
>
> I would be happy to help plan a few web pages that everyone who downloads
> blender would be asked to review asking them to rate which concepts they
> think would be useful for them in learning or using Blender.
>
> The server should send an email anyone who downs Blender, about 2 weeks
> later asking them to comment on what causes them problems, on where they
> look for information, on how they are learning. We should all read them all
> to get a feel for the problem.
>
>  It may be that others on this list that is out there somewhere have much
> better ideas than mine, but if we don't come up with a better plan this is
> the default that I suggest:
>
> I and a web page creator put on Blender.org the following new webpages
> directly linked as the documentation page.
>
> "Register in this form if you would like to be involved in creating a great
> manual for a great program."
>
> The form would contain questions for the contributor to define in what way
> they can help.
>
> They can choose to be
>
> *sub-editors* who download software and get their fingers into the servers
> data or
>
> *authors * who write explaining command or who write explaining methods or
>
> *contributors* who want to voice what they would like to see in the manual
> but who are not capable of actually doing it (newbies have the right to say
> what they need, but obviously they can't provide it)
>
> Decisions or plans of what the manual should contain and BE, would be
> published on those pages with feedback forms to check if it's what users
> probably want.
>
> Please make your suggestions.
>
> Do you want to build those webpages?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-docboard/attachments/20150114/901d3a62/attachment-0001.htm
>
> ------------------------------
>
> Message: 9
> Date: Wed, 14 Jan 2015 16:08:41 +0100
> From: brita <britalmeida at gmail.com>
> Subject: Re: [Bf-docboard] Specific plans and discussion of what our
>         manual should be and how to get it
> To: Blender Documentation Project <bf-docboard at blender.org>
> Message-ID:
>         <
> CAHaG9ayBR-Wn4-LRTEMWHGi5goWFVTDQ-TujPn-Co_6qr0dmQw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> These are mostly all topics that have been discussed on the wiki channel,
> considering the experience of several people.
>
> The manual is the manual. It is not a tutorial, it is not the python
> reference, it should not teach you graphics concepts as what is a camera or
> how to animate.
> There are other and more appropriate places for that.
>
> The manual is a comprehensive set of pages that cover the usability of
> Blender.
>
> Blender is also a very big software that encompasses many areas. It is
> difficult to make a linear manual that goes through everything only once in
> the right order, and that is short and readable while containing all the
> information that a user of varying expertise and background may ever wish
> for.
>
> The new tentative structure of the manual has been reviewed in the last two
> weeks. It now mainly needs a lot of reviewing and filling, making also sure
> that more people get on board and that the technology supports a good
> workflow.
>
> As to the organization of the collaborators, it is described in
> http://www.blender.org/manual/about/introduction.html
> that before was in blender.org/documentation.
> The information about the documentation is being unified in an hopefully
> clearer.
>
> The main idea is, there are section owners that get to decide things about
> their own sections and regular contributors. A new contributor should
> submit their changes for review before gaining access, as also explained in
> that documentation.
> The table with who owns what is being worked on right now. With the current
> status of the documentation, there are a lot of abandoned areas that need
> to be picked up.
>
>
> It is against Blender's philosophy to spam everyone that uses Blender with
> emails or polls or to silently fish information.
> People should be involved in their own way, at their own pace if they have
> such interest.
>
> It is important to communicate well (where do you find tutorials, what do
> you do if you are starting a commercial project .. ). The ways in which
> blender communicates, (mainly in blender.org) are always a work in
> progress.
> People are different and have their own ways and sense of privacy. Projects
> such as blender.org or the cloud or blender stackexchange or the manual
> need to grow on themselves. People will find them by needing and searching.
>
>
> Then this:
> "
> Those who already have downloaded whatever that stuff is that I couldn't
> even be bothered to read
> "
> is not really nice. If you really want to help, I suggest you actually read
> the
> http://www.blender.org/manual/about
> following the instructions to get started contributing.
> You could, for instance, review the User Preferences section to make sure
> that all options are up to date. Or get started with one of the new Editor
> pages.
>
>
> In?s Almeida / brita_
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-docboard/attachments/20150114/70e2ab27/attachment-0001.htm
>
> ------------------------------
>
> Message: 10
> Date: Wed, 14 Jan 2015 17:22:03 +0200
> From: Greg Zaal <gregzzmail at gmail.com>
> Subject: Re: [Bf-docboard] Specific plans and discussion of what our
>         manual should be and how to get it
> To: Blender Documentation Project <bf-docboard at blender.org>
> Message-ID:
>         <CAN5-zsMvuOC6PZJtotEanh6jj7rub2sETc41C_RYCcvH=
> vZ2yA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hey Abuelo,
>
> We discussed what the new manual should be a little while ago on this list
> - there seemed to be a general consensus that it should be both a technical
> reference ("button X does this") and a topic-driven guide. Different
> sections of the manual are suited to either one or both of those. (See the
> archives
> <http://lists.blender.org/pipermail/bf-docboard/2015-January/thread.html>,
> in thread "Proposal for restructuring the user manual").
>
> Breaking it up into sub-editors, authors and contributors is an interesting
> idea. I agree that someone should be able to suggest a change to the manual
> without needing to set up SVN, but this can already be done by creating a
> task here: https://developer.blender.org/maniphest/task/create/?project=53
> .
> Being a sub-editor would be a pretty crappy "job" I think - receive emails
> from random people demanding you to make some change, and then you're left
> to sort out correct formatting, uploading images and commit it.
>
> Sending an email to every blender user 2 weeks after they download it is
> not acceptable at all IMO, but you can easily start a thread on
> blenderartists.org to ask them (possibly do a poll there).
>
> I think it would be best if you could join our IRC channel for a few
> minutes (click here
> <http://webchat.freenode.net?nick=abuelo...&channels=%23blenderwiki&uio=d4
> >,
> type in the captcha, and you're in) to chat with us - just to make sure
> we're all on the same page and to avoid starting discussions that have
> already been had.
>
> Finally, I'd really appreciate if you try to set up SVN and make some edits
> to the manual (here's a simple guide I wrote to help:
> http://blender.org/manual/about/install/windows.html) - it's really not as
> hard or complicated as you think it is - I'm primarily an artist myself.
>
> Cheers,
> Greg Zaal
>
> On 14 January 2015 at 16:12, Abuelo S. B. Chdancer <playadance at gmail.com>
> wrote:
>
> > Top level design:
> >
> > What should a manual be and how do we get one?
> >
> > 1) Quick reference guide to all commands?
> >
> > 2) Topic based manual of what you might want to do and how to do it?
> >
> > 3) A place to learn step by step?
> >
> > Lower level design:
> >
> > What is a normal page to look like?
> >
> > How should one page lead or connect to another? (Has the tech already set
> > this?)
> >
> > What should the overall plan for the entire work be?
> >
> > Contributors:
> >
> > Finding that rare combination of someone who intimately knows parts of
> > Blender and is willing and able to explain it to someone who doesn't
> > understand shouldn't be messed up by also requiring that person to be
> > technically proficient and willing to learn new software simply to tell
> > their story.
> >
> > If that software is needed to get the text and pictures into the server -
> > let those who use it be *sub-editors* and let the *authors* communicate
> > with sub-editors using simple software that everyone already has - email
> &
> > browser.
> >
> > I would tell other potential contributors that they need to indicate in a
> > simple webform what they feel able to help on, and tell them that sending
> > in their contribution will be technically similar to posting a comment
> on a
> > website - nothing to download, no programming skills needed.
> >
> > The various ideas would need to be cut down to practical designs and
> could
> > then be again displayed on webpages for public review.
> >
> > When the design of the work has been decided which includes details of
> > what individual pages should have in common and what should be different
> > the minor stylistic decisions can be made about whether writing is to say
> > "You can" rather than "It is possible to.."
> >
> >  We need a few web pages that everyone who downloads blender would be
> > asked to review asking them to rate which concepts they think would be
> > useful for them in learning or using Blender.
> >
> > I would do a survey of users to try to understand what they/we need or
> > want from documentation.
> >
> > I would send an email to anyone who downs Blender, about 2 weeks later
> > asking them to comment on what causes them problems, on where they look
> for
> > information, on how they are learning. I would read them all to get a
> feel
> > for the problem.
> >
> >  So I suggest the following:
> >
> > Those who already have downloaded whatever that stuff is that I couldn't
> > even be bothered to read - they should be initially *sub-editors *who can
> > receive contributions from other simpler folks like me, that *sub-editor*
> > then uses that software stuff to get the data onto the server.
> >
> > Some web page creating type is needed to set-up the following fairly
> > simple webpages that I am suggesting, or something similar where normal
> > contributors can register their willingness and their self-claimed level
> of
> > expertise. I would be happy to work with the webpage creator.
> >
> > I would be happy to help plan a few web pages that everyone who downloads
> > blender would be asked to review asking them to rate which concepts they
> > think would be useful for them in learning or using Blender.
> >
> > The server should send an email anyone who downs Blender, about 2 weeks
> > later asking them to comment on what causes them problems, on where they
> > look for information, on how they are learning. We should all read them
> all
> > to get a feel for the problem.
> >
> >  It may be that others on this list that is out there somewhere have much
> > better ideas than mine, but if we don't come up with a better plan this
> is
> > the default that I suggest:
> >
> > I and a web page creator put on Blender.org the following new webpages
> > directly linked as the documentation page.
> >
> > "Register in this form if you would like to be involved in creating a
> > great manual for a great program."
> >
> > The form would contain questions for the contributor to define in what
> way
> > they can help.
> >
> > They can choose to be
> >
> > *sub-editors* who download software and get their fingers into the
> > servers data or
> >
> > *authors * who write explaining command or who write explaining methods
> > or
> >
> > *contributors* who want to voice what they would like to see in the
> > manual but who are not capable of actually doing it (newbies have the
> right
> > to say what they need, but obviously they can't provide it)
> >
> > Decisions or plans of what the manual should contain and BE, would be
> > published on those pages with feedback forms to check if it's what users
> > probably want.
> >
> > Please make your suggestions.
> >
> > Do you want to build those webpages?
> >
> >
> > _______________________________________________
> > Bf-docboard mailing list
> > Bf-docboard at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-docboard
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-docboard/attachments/20150114/987cce19/attachment-0001.htm
>
> ------------------------------
>
> Message: 11
> Date: Thu, 15 Jan 2015 08:35:48 +0800
> From: Pep Ribal <pepribal at gmail.com>
> Subject: Re: [Bf-docboard] Being involved In documentation
> To: Blender Documentation Project <bf-docboard at blender.org>
> Message-ID:
>         <CAOOWns6eKjrCHgWK5xEA4m+52=
> kby-wLfP+70ptGq5Xb2sFKig at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2015-01-14 21:19 GMT+08:00, Campbell Barton <ideasman42 at gmail.com>:
> > On Wed, Jan 14, 2015 at 5:12 PM, Pep Ribal <pepribal at gmail.com> wrote:
> >> I think that some Project Management skills should be poured in. A
> >> "project
> >> manager" should be appointed. A few key positions should be filled
> >> (official
> >> writers), and an official documentation team should be set up. If we
> have
> >> a
> >> team of developers, an official team, with a clear coordinator and a
> clear
> >> team of key developers, each one responsible for his module, why not
> have
> >> the same for documenters? That's what the documentation project lacks.
> >> There
> >> is no official team. So there is not a feeling of "important
> department".
> >
> > Agree, but we need someone who is naturally good in the role of
> > helping people work together, not just someone who comes in and says
> > they will tell others what to do.
> >
>
> If we agree that this position is needed, my suggestion is to look for
> that person right away. In any company, it's the obvious thing to do
> (needed? hired!), so why not make an announcement right away, using
> the lists, blender website, etc.? Something like:
>
> "Team leader wanted, responsible for the development of the official
> Blender documentation. Skills needed: proven leadership, project
> management, Blender knowledge, etc. (just an example)"
>
> I think it can turn the Blender manual status from "stuck" to "in
> progress".
>
> If that person were found, and he/she were good enough, he/she would
> be able to motivate people and build up an appropriate team of
> writers, for sure.
>
> Pep.
>
>
> ------------------------------
>
> _______________________________________________
> Bf-docboard mailing list
> Bf-docboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-docboard
>
>
> End of Bf-docboard Digest, Vol 119, Issue 11
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-docboard/attachments/20150115/13db3d2e/attachment.htm 


More information about the Bf-docboard mailing list