[Bsod-mentors] Ideas and comments.

[Ton Roosendaal]

Hi,

I would advise to not overshoot too much in over-organizing the  
project. There's no reason to scare away people, nor do I think we get  
100s of submissions in. :)
My experience with the Google project is that the complexity of  
rules/methods is not working well. This year they've organized it "much  
better", causing in a load of confused traffic on the mentor list.

Mixed in below some comments.

> Ok topics we need some thought and discussion about -
>
> a) Proposals - structure of proposals, what we expect to be contained  
> in the proposal, level of detail, how to present them (wiki, bsod  
> board on b.org, email to list, etc etc.)
>
> I've discussed things a little with spiderworm and come up with some  
> ideas for sections that should be present in the proposals.  The  
> structure we came up with is as follows -
>
> -Intro/Synopsis - General introduction to the proposal in a paragraph,  
> or two.
> -Justification - How is it to benefit the user base?
> -Scope/Detailed breakdown - Tell us exactly what will be detailed in  
> the docs produced
> -Deliverables - Tell us what you plan to give as end result, in terms  
> of quantity, type, etc
> -Outline/Timeline - (unsure if this is necessary) speaks for itself
> -History/Biography - tell us what experience you have, what have  
> contributed in the past, prove you can do what you say.

This is a bit too much I think. It's not a lifetime job people are  
applying for! What about this:

- Intro/Synposis: one paragraph summarizing the proposal
- Scope/Breakdown: what topic(s) will be covered, and how will it be  
structured.
- Deliverables: what the result will be, in terms of quantity, type, etc
- Biography: past experience, links to existing work, etc

> We also came up with the notion of having a small writing challenge,  
> maybe asking for a couple of small writing tasks, maybe say 200 words  
> each, a technical example, maybe something creative or research based,  
> and an editing task where we give them a bad text and ask them to edit  
> it accordingly.

You could do this, but just based on personal contact with people who  
sent in a great proposal but didn't show any past experience. Don't  
oblige everyone to this.

> b) Qualifying for the project - what should we ask for in regards to  
> past experience if any? what should we ask to be demonstrated? should  
> we ask for image proof that the person is competent with the area of  
> Blender they want to document?

You can mention that the submission should have sufficient information  
for the mentor team to decide if it's eligible. This can be past  
experience, or samples of work, etc.

> Obviously if we set a writing task as part of entry conditions then  
> that would demonstrate the writing ability of the candidate, though  
> this has an inherent problem, language.  We would need to find a way  
> of providing a fair test there, and since their text will be  
> translated anyway, it seems we should really be testing the  
> translator.

Translations is a difficult topic yes... I don't like to complexify  
this whole grants system by also giving money to the translators. What  
about this offer; a translator can do a free pick from the Blender  
e-shop?

> I don't like the idea of requesting past experience documenting since  
> it limits people who could provide a great contribution, that said, I  
> think we need to be especially critical of their ability in the  
> designated area, and in their writing ability if they don't have  
> experience already.

I agree. You could use the description as I provided before. You guys  
need *some* evidence!

> c) Theme - As we mentioned in the original b.org post, we'd like to  
> involve a theme for the overall scheme of the project.  That way we  
> get a unified end result.  The choices that we have got so far, are-
>
>   i) Blender Basics Bootcamp - a detailed introduction to the major  
> areas of Blender, maybe leading into some more advanced topics, for  
> example docs on lighting could include radiosity for example.
>
>   ii) Blender Since 2.3 Manual - detailed guides to the major feature  
> releases since 2.3, things like new animation, fluids, softbodies,  
> compositor etc etc
>
> What are the general thoughts about these themes, and has anyone got  
> any ideas for other themes?

I'm fine with any. You guys decide. :)

> d) Mentor role - should there be a 1:1 ratio participant to mentors?  
> do we need to provide each participant with a particular mentor, I  
> think that as much as possible we shold try to organise a meeting  
> between the participant and the person responsible for the project,  
> and of course, non-English participants will have to have a buddy for  
> translating etc.

Limit the mentor role to an absolute mininum. In Google the target is  
different (get students into new projects, so they need guidance). We  
can just assume that any documenter should know Blender well enough to  
be able to write about it.

The mentors can limit work to answering to questions, and try to be  
clear about expectations you have for a succesful completion. The  
people on this list can be 'mentor', no need to find more I guess.

> e) Format - I think the best option is for directly working onto the  
> wiki here, to allow us to see what is going on and to involve  
> individual mentors if we decide to take that path.

Good!

> Anyway that is all i've got for now, lets get some comments happening  
> and set the ball rolling.

Thanks for the good work mate!

-Ton-

>
> -Tim
> _______________________________________________
> Bsod-mentors mailing list
> Bsod-mentors at blender.org
> http://projects.blender.org/mailman/listinfo/bsod-mentors
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org