[Bf-committers] Wiki reorganization proposal

[Campbell Barton]

Notice hidden in this proposal is moving scripts over to the scripts
repo 'bf-scripts'

Im ok with this providing...
* SVN history must be maintained - "svn blame" needs to work, not sure
if this will pose a problem.
* bf-scripts are added to bf-blender as an external repo, "svn up"
should pull in the latest scripts also. (no manually copying scripts
over)

On IRC we also discussed giving access to scripters who can commit
their own scripts that may eventually be released with blender but for
the time being these could be called "contrib" scripts that are not
officially supported.

There are a number of ways to deal with this, however Id suggest we do this....

Move  bf-blender/trunk/release/scripts/*  to  bf-scripts/trunk/
 (make bf-blender/trunk/release/scripts  point to  bf-scripts/trunk as
mentioned above)

Add a directory in bf-scripts for unsupported, user contributed
scripts: bf-scripts/trunk/contrib/
 This means people who are updating bf-blender and building it from
source can test new scripts in contrib, which is important to get
these scripts tested and possibly made into a releasable script.

Add an option to scons option to be used with releases
BF_CONTRIB_SCRIPTS for instance. Otherwise the contrib directory will
be omitted.

Blender will add contrib scripts to the menu's if the "contrib"
directory is present.

With Blender 2.5 possibly hosing all existing scripts I don't want to
waste too much time on this issue.

On Mon, Jan 12, 2009 at 8:02 AM, Brecht Van Lommel <brecht at blender.org> wrote:
> Hi,
>
> One thing that this proposal doesn't focus on much, is how to get this
> effort organized. And I don't mean so much guidelines, but who is going
> to lead it, and how you're going to attract people to do the work. I
> think it is important to make things more transparent and inviting,
> which means:
>
> * Regularly publish what has happened and open tasks for people to
> participate in, on blenderartists or blendernation for example.
>
> * A point of access for people wanting to participate. A mailing list,
> forum or even personal e-mail address for people who want to get
> involved should be there and _responsive_. Of course there are the
> blender.org forums, #blenderwiki, and bf-docboard but the point is that
> there should be at least 1 person who is actually following that and can
> answer questions and distribute tasks.
>
> * As mentioned, ideally no restricted editing rights.
>
> On Sat, 2009-01-10 at 15:53 +0000, mindrones wrote:
>> after talking with some of the people involved in wiki,
>> I've written a proposal to reorganize the actual wiki
>> http://wiki.blender.org/index.php/User:Mindrones/blender-wiki/proposal
>> and posted in docboard mailing list.
>
> Doc/Ext/Dev/Org/Meta/Attic make sense to me. The "theory" thing could be
> interesting but I would advise to only make website section if you know
> it is going to be filled and maintained. I think it would be good to
> move _a lot_ of stuff to the attic. It's not because someone invested
> effort that it should be very precious, if it's old, outdated or very
> incomplete then it should be moved there in my opinion, with a clear
> warning. That applies to easily 50% of the front page table of contents.
>
> I think it is more useful to do less better, and move a lot to the attic
> and move it back only when it meets some obvious quality criteria
> (though there can be redirects of course to not break links).
>
>> Now it is based on workflow (how informations flow to and from wiki)
>> and it's awfully long :)
>>
>> It would help a lot to hear suggestions from committers, so that we can
>> put down a list of priorities (most useful/easier things first).
>
> I think things that add more _maintenance_ work should be low priority.
> Things that require effort to keep updated in fact may do more harm than
> good if they are not kept updated, and this a big problem with the wiki
> now. If you click a link you have no idea if it is going to lead you to
> anything interesting or even correct still.
>
> There is already enough work to get the wiki organized better with the
> current information that it tries to provide. So in my opinion these
> things are not important and perhaps are better to leave out even.
>
> * Tagging and semantic wiki: can't we first try to organize the wiki so
> you can actually find things by looking at the table of contents?
>
> * Organizing feature requests: blenderstorm?
>
> * Overview of tagged commits in the wiki: too much maintenance with no
> clear purpose over just reading bf-blender-cvs.
>
> * Trackers for scripts: not really a job for the wiki, if someone wants
> to organize this better that is fine .. but better to not mix that in
> here.
>
> * Tracker for blend files: too much work and will be outdated and
> incomplete quickly.
>
> * Page scheme: if the existing pages are properly formatted copy-paste
> works just fine.
>
> * Read wiki inside Blender.
>
> * Imagemaps to navigate manuals from Blender screenshots: to much work
> too maintain.
>
> * Section map: not that useful.
>
> Brecht.
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell