[FM Discuss] FM upstream to Sugar Labs

Sat Jun 28 05:41:11 PDT 2008

On Sat, 2008-06-28 at 04:54 -0400, Walter Bender wrote:
> I'll try to help get the word out to the volunteer community. On a
> more mundane level, Is there a description of the preferred workflow?

see the manual:
http://www.flossmanuals.net/flossmanuals

> Is there some sort of trac system for handling
> requests/bugs/priorities etc?
> 

this is left largely to the discussion list. i am contemplating a
'manual planner' extension for fm but it won't be in place until i have
a good idea of what it should look like. there will be some discussion
about this at the inkscape book sprint in a week or so

adam

> -walter
> 
> On Thu, Jun 26, 2008 at 10:59 PM, Anne Gentle <annegentle at gmail.com> wrote:
> > Hi again all,
> >
> > I'm frankly excited to hear Sugar Labs' enthusiasm about doc. It really has
> > taken a community effort and knowing that doc could see some synergy with
> > def effort is great.
> >
> > I have ideas for getting more energy behind some of the separate doc
> > deliverables we could target, and have already sent out a couple of emails,
> > especially in pursuit of a Turtle Art "manual" that a Houstonite put
> > together, and I think she'd be willing to post it on FM.
> >
> > So, an approach would be similar to what we've done before - when we have a
> > well-defined task analysis and outline for a manual, we start recruiting
> > writers for it. If writers volunteer, we can have specifics for them to work
> > on.
> >
> > As for tracking doc bugs and requests, I'd love to have doc requests
> > prioritized just like software bug are prioritized. That approach would let
> > us figure out how to "staff" the different projects and also would work well
> > towards a Book Sprint. Adam, I have a writer her in Austin who was just
> > asking about that on her blog, and maybe we could get her and one other
> > interested person to write for a burst of time if we have a prioritized set
> > of docs to work on.
> >
> > Um, let's see, does that cover the spirit of the questions and approach? I
> > hope I'm not missing anything or misrepresenting a typical approach.
> >
> > I'd be happy to coordinate with volunteer writers you send my way - I
> > already have templatized email responses from OLPC work that I can revise
> > for those who want to volunteer for OLPC/Sugar docs on FM.
> >
> > Thanks,
> > Anne Gentle
> > e:annegentle at gmail.com
> > b:www.justwriteclick.com
> >
> > Message: 1
> > Date: Tue, 24 Jun 2008 19:11:53 -0500
> > From: David Farning <dfarning at sugarlabs.org>
> > Subject: [FM Discuss] FM upstream to Sugar Labs
> > To: discuss at lists.flossmanuals.net
> > Message-ID: <1214352713.32315.91.camel at dfarning.desktop.org>
> > Content-Type: text/plain; charset=UTF-8
> >
> > I spent a good part of today thinking about how FM and SL could
> > collaborate in a way that was beneficial to both of us.
> >
> > I keep coming back to the upstream/downstream relationship between
> > software packages.  When I write a program in c, I don't rewrite the
> > compiler.  I use gcc.  It makes no sense spending the time required to
> > learn compiler theory and hack away on my own.  The gcc project has
> > already assembled the expertise and processes to do a better job than I
> > ever could.
> >
> > I am thinking about using FM documentation in the same manner.  Sugar
> > Labs has nowhere near the time or manpower to create documentation as
> > effectively as FM.
> >
> > I hope that I did not appear as if I had a laundry list of things I
> > would like FM to do for me.  Rather, ?I would like to:
> >
> > 1.  Ask your permission to use your documentation as our primary user
> > documentation.
> >
> > 2.  Request that we work together to create the 'canonical' Sugar and
> > Activities documentation.
> >
> > 3.  Express that we are not expecting you to write our manual.  Instead,
> > we are using your manual about our product.
> >
> > In return we will:
> >
> > 1. Always keep the documentation open.
> >
> > 2.  Send patches back upstream if we find bugs or ways to improve the
> > manual.  (Sending patches and finding bugs is not the right terminology,
> > but you get the idea.)
> >
> > 3.  Direct potential documentation writers to you to help build your
> > community.
> >
> > Thanks
> > Dfarning
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Wed, 25 Jun 2008 03:32:59 +0200
> > From: adam hyde <adam at flossmanuals.net>
> > Subject: Re: [FM Discuss] FM upstream to Sugar Labs
> > To: discuss at lists.flossmanuals.net
> > Message-ID: <1214357579.7274.21.camel
> > @resetera>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > hi,
> >
> >
> >>
> >> I am thinking about using FM documentation in the same manner.  Sugar
> >> Labs has nowhere near the time or manpower to create documentation as
> >> effectively as FM.
> >
> > It sounds good to me, except you should note that FM is in some ways a
> > collection of communities. The OLPC manual is headed up by Anne and
> > several others have also worked on it. In this sense you could imagine
> > FM to be a smaller friendlier version of source forge. There is a
> > platform established for making manuals - but each manual must work out
> > its own way of getting contributions. For this reason I think Anne is
> > the FM touchstone on OLPC/Sugar manuals as she has already started this
> > process.
> >
> >> 1.  Ask your permission to use your documentation as our primary user
> >> documentation.
> >>
> >
> > All docs are GPL. So you are free to do with them as you like. Thats
> > actually the point but its very nice of you to ask :)
> >
> >> 2.  Request that we work together to create the 'canonical' Sugar and
> >> Activities documentation.
> >
> > sounds good to me. We should perhaps discuss how to bring others into
> > the project. Some on the FM list maybe interested but there are also
> > other strategies. Anne and I had considered applying for a small amount
> > of money to have a Book Sprint on Sugar...I think this could be a very
> > effective way of not just producing material but getting everyone
> > heading in the same direction.
> >
> >>
> >> 3.  Express that we are not expecting you to write our manual.  Instead,
> >> we are using your manual about our product.
> >> In return we will:
> >>
> >> 1. Always keep the documentation open.
> >>
> >> 2.  Send patches back upstream if we find bugs or ways to improve the
> >> manual.  (Sending patches and finding bugs is not the right terminology,
> >> but you get the idea.)
> >>
> >> 3.  Direct potential documentation writers to you to help build your
> >> community.
> >
> >
> > I think its worth getting Annes thoughts on the above :)
> >
> > adam
> >
> >
> >>
> >> Thanks
> >> Dfarning
> >>
> >>
> >> _______________________________________________
> >> Discuss mailing list
> >> Discuss at lists.flossmanuals.net
> >> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net
> > --
> > Adam Hyde
> > FLOSS Manuals
> >
> > http://www.flossmanuals.net
> > + 31 6 2808 7108
> >
> _______________________________________________
> Discuss mailing list
> Discuss at lists.flossmanuals.net
> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net
-- 
Adam Hyde
FLOSS Manuals

http://www.flossmanuals.net
+ 31 6 2808 7108
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.flossmanuals.net/pipermail/discuss-flossmanuals.net/attachments/20080628/4768b0a1/attachment-0001.pgp>