Hi Zelgadis!
El 14 de abril de 2010 08:55, Zelgadis <[email protected]> escribió:
> Hi!
> It's Zelgadis.
>
> 2010/4/14 Carlos López González <[email protected]>:
> > Thoughts? :)
> >
> > ---------- Forwarded message ----------
> > From: Oliver Horn, Oho! Services <[email protected]>
> > Date: 2010/4/14
> > Subject: Next steps / doc help needed // was: Re: Hello
> > To: [email protected]
>
> >> Honestly at this moment we are a bit "disorganized". Just
> >> three (or may be two) people does care on the whole stuff:
> > wow, that's few for this kind of project... (we should work on that
> > immediately, more people needed asap!)
> I just contacted Prokoudine this morning asking him if he will offer
> his help with documentation. ^___^
>
> Prokoudine is a good brained head. I do support ask him for help :)
> >> We sincerely embrace any kind of external help :)
> > Ok, not much time left on my side, but I will do some work for sure...
> >
> >> 1) Translation. Please follow this guide and if you still
> >> having problems please contact me or try the forums.
> >> http://synfig.org/wiki/Dev:Translation
> > having read the rest I think we should postpone translation work for a
> while
> Totally agree.
>
> Me too
> >> 2) Documentation: I would ask for help on organize the
> >> documentation rather than translate it.
> > I'm good in project management and structuring things (actually my main
> > job is around IT architecture and project management), as well as doing
> > some marketing... So, when you need help here: I'll do it. (see question
> > 1 below)
> Writing Solid Manual for Synfig (Documentation) was my next step in my
> plan (http://synfig.org/wiki/Dev:Roadmap#Web_infrastructure_reorganization
> ).
> I appreciate any help here.
> I think we should focus on reorganizing existing wiki content rather
> than writing new pages. So the plan was to analyze existing pages, put
> them into structure and add new pages only when needed. I did this
> here: http://synfig.org/wiki/Category:Manual.
> I have set up PDF export on the wiki to ensure that we will be able to
> have good output. That works fine.
> Next steps:
> - We need to rewrite pages to put them together into solid manual.
> Pages in manual should form logical sequence, but at the same time
> each page should be complete description of particular theme. I
> imagine manual as a book. Manual not covers EVERY aspect of Synfig.
> It's purpose to guide user through essential concepts of animation
> production process in Synfig Studio. If user need a complete list and
> detailed description of each Synfig function, he will read Reference.
> - Lots of pages have outdated information - update them according to
> latest release.
> - Update screenshots
> - Proofread (English is not my native)
>
> >> Starting from
> >> zelgadis macros that allows quick and easy translation of
> >> each page and based on a preliminary structure made by
> >> zelgadis, synfig.org/wiki is our main documentation
> >> database.
> > Do we know who did something in the docs so far?
> > Do we know about the translators?
> Didn't understood what those questions about... ^_^''
>
> Oliver, Documentation is hold by a wiki system. It is open (just with
moderation restrictions) to any user. Just read the wiki changes and you'll
know who change what
There are not official wiki translators. People come and go. I could
eventually be official translator for Spanish but I have enough on my plate
at the moment.
> > I would like to recruit everyone possibly interested in working on the
> > doc. We should stop working on translations if major changes to the doc
> > are necessary, but that is also a good chance to get the translators
> > work on the original doc.
> >
> > I need contacs and I need some help on bringing up some "call to action"
> > on the website. We need a place to discuss general structure.
> > I plan to come up with a rough concept and have the others discuss that
> > for a while. Then close discussion, define work packages and get things
> > done...
> >
> > Who can help me ...
> > - getting the names/contacts?
> - Me and Carlos. Regarding to help with documentation I think we need
> small core team who will develop main content. You, Carlos, me, maybe
> Prokoudine, maybe ? (But maybe Carlos will prefer to stick with the
> code?)
> > - putting some content on the website (not yet, but when I need it...)?
> - Me and Carlos
> > - getting the needed infrastructure for dicussion and development work
> > (in the wiki I guess)? Maybe also using SourceForce bug reporting?
> - Me. I suggest use wiki to develop documentation and use mailing list
> or forum for discussion.
>
> I'm forwarding this email to devel mailing list.
> >> There are pending some articles that still being
> >> in the wiki that are not documentation related (news,
> >> gallery, etc.) They have been moved to the joomla website
> >> slowly and lately we need help on that too. I can provide
> >> you website Redactor rights if needed.
> > Ok, I would like to start with the doc, let's come to the website later.
> I have some thoughts on that, but I prefer to confess them in public
> on the forum.
>
> >> I'm in a personal ihatus that I will close as soon as I can.
> >> My next step is to release the new version so any help is
> >> welcome.
> > I'd like to learn about the new version for planning the doc then.
> > Time: Code freeze/Tests/Release planned when?
> Ask genete. ^__^
>
The schedule is not so riggid at the moment due to I don't know if I can
follow strictly.
Anyway, the idea is:
-Code freeze and release candidate #1 around April 21
-Call for translations and new icons/artwork patches
-Known bugs fixing from April 21 to 30
-April 30 ends Splash screen contest
-May 1st: release candidate #2
-May 1-7 Splash voting pool
-May 7 - 12 Needed code changes for release. Latest bug fixing, translation
patches, artwork, copyrights.
-Around May 15 Final release.
> Content: Any overview about the accepted changes available? Functional
> > changes? UI changes?
> The best way to get list of changes is to look through git revision
> history. IIRC there are not much changes:
> - Normal tool improved to Unified transform tool
> - Improved FFMPEG export
> - Improved SVG export
> All the rest are bugfixes.
> I think we should collect changes made in release on separate page
> like blender does:
> http://www.blender.org/development/release-logs/blender-249/
>
I agree on that ^^
> > -> decision needed: shall we plan to do the doc for the new release or
> > does it make sense to still work on the doc for 0.62? I guess we would
> > need at least 3 months to finish a consistent doc. Maybe we also should
> > just quick-fix a few areas first, to make sure we do not loose any users
> > meanwhile. (see question 2 below)
> I think we should target on upcoming 0.62.01. It will have not much
> changes. And it's better than target on outdated release.
>
> > My questions to you now:
> > 1. shall I take responsibility for structuring/planning the doc
> development?
>
> I suggest to look on the existing structure first an discuss it,-
> http://synfig.org/wiki/Category:Manual
>
> > 2. what do you think about the point mentioned above: doc for 0.62,
> > 0.63, intermediate steps needed?
>
> 0.62.01
> This version will be released in May. We still be working on the doc.
> While we writing it, the development will continue towards the 0.62.02
> (or 0.63.00). If we will want to reflect in documentation some changes
> made for the upcoming (not yet released) version, we will mark those
> paragraphs as "Development Version" and put those pages into
> "Development" category. So when release will happen we just update all
> pages into development category.
>
> Also we should track status of each pages in manual. Each page should
> be marked as Unverified or Updated or Verified. Then development cycle
> is simple:
> 1. When new synfig version is released we mark all pages in manual as
> Unverified
> 2. We read through all manual and documenting changes made in release.
> That includes inspecting paragraphs marked as "Development Version",
> updating screenshots, etc. Pages passed through this stage marked as
> "Updated".
> 3. Someone with native English proofreads pages marked as "Updated".
> Pages passed through this stage marked as "Verified".
> 4. Goto 1.
>
> My suggestion is to continue that discussion in synfig-dev mailing list.
>
> I suggest to do the following:
Once the wiki page is reviewed/updated to be consistent with a particular
synfig version mark it as: "Verified for 0.62.01" So when we come back to
the page and noticed that there is not change in the new release that
affects the wiki page we can bump the "Verified version" quickly
> Cheers!
> K.
>
> --
> http://morevnaproject.org/
>
Cheers!
--
Carlos
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Synfig-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synfig-devl
