ltsp local apps + nat + ....

Ace Suares ace at
Wed Jul 22 21:44:45 BST 2009

Scott, thanks for the elaborate mail. I will react on details later. For 
now I just want to ask you what about packaging the documentation, I 
volunteered to do that if I can get an estimate on how much time it will 
cost and some simple steps how to do it.

Are you gonna take me up on that offer ?


Scott Balneaves wrote:
> On Wed, Jul 22, 2009 at 01:43:52PM -0400, Ace Suares wrote:
>> Scott Balneaves wrote:
>>> On Wed, Jul 22, 2009 at 11:29:37AM +0100, Gavin McCullagh wrote:
>>>> It's a little frustrating to have people complain on their blog about how
>>>> bad a wiki is, but yet not actually take the five minutes to correct it or
>>>> even draw attention to the problem in the community.  However, I know
>>>> the real developers have much greater frustrations.  I have attempted to
>>>> clarify the issues.
>> Actually, it takes more then five minutes to edit a wiki. Especially if 
>> you have never done it before.
> That's where the learning part comes in.  Editing a wiki is easy, once you take
> the 15 or 20 minutes to play around with it and learn how to do it.
>> This is one of my main issues - it takes 
>> too much time for a *casual* contributor to update the wiki.
> A tool was needed to allow people, developers, users, anyone, a common place to
> be able to have a common, collaborative place to write documentation.  A wiki,
> much like a huge number of OTHER projects, was chosen as the easiest way to
> make this happen.
>> First there 
>> is the problem on which wiki, as discussed in another post on this list, 
>> then there is the learning curve towards the wiki.
> ---+ A title
> ---++ A larger title
> a paragraph of text
> ===courier font text for program listings===
>  * Bullet
>   * second level indent.
> 75% of everything you need to know about wikis in about... 9 lines, including
> blanks :)
>> Maybe you are a full time developer / contributor to Edubuntu or Ubuntu 
>> and you are familiar with all of its tools. Other people are just 
>> chipping in occasionally, and maybe doing that on many different 
>> software projects. The difference adding some documentation to Moodle 
>> and Edubuntu and Postfix is huge! (and I use those + PHP and qmail-ldap 
>> and openldap and amavis and linux and gnu and clamav and apache (1 and 
>> 2) and ruby and rails and plugins and open office and and and).
> And each of these projects probably has their OWN documentation methods: wikis,
> docbook documents, stock HTML, etc.  Contributing to a Free Software project is
> non-trivial.  But, as always, you *get out of it* what you put into it.
>> Try thinking as a not so experienced developer.
> We do. Constantly.  That's why there's the channel, the mailing list, heck, if
> you want my phone number, you're welcome to *call* me :)  But we can't make
> *everything* go away.  Like it or not, Ubuntu and Edubuntu, like any other
> project, picks tools it's going to use *at the beginning*, and you're kind of
> stuck with those choices from then on... unless you want to spend a significant
> amount of your resources taking stuff of the wiki, and putting them into
> moodle.  And then after moodle, the next CMS hot topic to come along.
>> And try thinking why 
>> these people complain about stuff instead of contributing. If it was 
>> really all that simple, would people still choose to complain instead of 
>> contributing?
> How would you suggest we make the process of contributing to say, the
> documentation, any easer than what we have? I'm not being facetious, or
> argumentative, I'm honestly asking.  If there's something we can do to *make*
> it easier, fine, let's do it.
>> Even with that amount of experience - as said, no developer but 
>> certainly not a newbie - does not make it possible for me to *quickly* 
>> change an error in documentation or one line in the software.
> But the bottom line is, we can't make it *instantaneous*, there has to be
> *some* structure, *some* tool that's acting as a gateway.  Whether that's
> moodle, or a wiki, or whatever, someone's going to HAVE to learn *something*.
> I give you my *personal* guarentee it'll take you 20 minutes, TOPS, to learn to
> edit a wiki.  I'll even TEACH you.  You know the channels I hang out in, Ace,
> #ltsp and #edubuntu.  I'm there *right now* :) Pop by and I'll show you.
> And to anyone else out there: *any* developer who's on these projects will
> *gladly* spend some time with anyone who comes by and says "if someone shows me
> how to do X, I'll pay you back by contributing my time to helping to maintain
> X".  Heck, we'll be falling all over each other to help.
>> For additions to the software I might have to install and learn to use: 
>> git, cvs, svn, bzr, to name a few. I might have to make various accounts 
>> on various sites, sometimes more then one account for the same 
>> 'product'. I might have to download a tarball, make changes, do a diff 
>> with some options, and send it back to a mailing list. And so on and so 
>> on. It's very complicated for someone who spends only now and then on 
>> developing software or improving docs. 
> It's what we have to do.  It's what I have to do day in and day out.  It's the
> way software development is done. And *I* don't get paid for it.  I do this
> *completely on my own dime*.  You just said you make 100% of your income from
> this.  I'm not asking for money, or recognition.  The way you can pay back the
> community for their contribution to your income is by spending some of YOUR
> time to become part of the process.
> <snip>
>> Compare it to uploading a photo on flickr. It's very easy. Everyone 
>> understands the interface (or at least can learn very quickly).
> I think we could agree that there's a pretty big difference between fixing bugs
> in complicated pieces of software versus uploading pictures to a web site.
>> Yes there are many people nowadays who just fill in bug reports the way 
>> you describe. Go check my homepage on launchpad, bug department 
>> ( Take a look at the bugs I 
>> submitted and if they fall under your description. Look at the number of 
>> bugs that are still in 'New' or 'Confimed'. Some of them are years old.
> None of the comments I made were aimed at you specifically.  However, if large
> numbers of bugs are still new or confirmed, and not fixed, maybe that's an
> indication of how busy everyone is.  Remember, MOST of us are volunteers, and
> don't get paid to fix these bugs.
> Let me ask the obvious question:  Why do you feel it isn't *just as much your
> obligation to fix the bug*, as it is to report it?
>> What I try to say that the people who do more then just 'bitching on 
>> bugs', people that really take an effort to describe a bug, are put off 
>> by the reaction to those bugs. Some of them are never picked up. Some of 
>> them are just plainly told to go to a totally different site (for 
>> instance 'upstream' or bugzilla or whatever).
> Because that's the best place for them.  If somethings an upstream bug, it
> needs to get filed there.  C'mon Ace, if you've been involved since 1994, you
> should *know* how the community works by now.  Edubuntu's a distro, it doesn't
> *write* the software it uses.
>> I can tell you from my own experience that filing bugs is NOT very 
>> rewarding. I joined bugsquad for a while but got hopelessly lost on 
>> discussions, rules, wiki pages and so on. I see that bugsquad is really 
>> trying hard to improve things, and the hug days are a good thing for 
>> team spirit, but it's still a long way from raking in that casual 
>> developers and contributors.
> So, once again, what's the solution?  How can we make things easier?  Ok, lets
> say we're not going to kick things upstream.  Lets say, starting right now,
> Edubuntu, the entity, is going to look at every bug, fix it, and if upstream
> needs fixing, we'll spearhead it.  You just said you gave up on that because
> you "got hopelessly lost on discussions, rules, wiki pages and so on.".  But
> fixing bugs is *hard work*, you've got to stick with it.  If we're going to
> make things easier on the end user then *someone* has to stick with it.  And
> that someone's gonna be unpaid, as this is a community run distro.
> Or alternatively, someone could pay to have a fulltime "edubuntu bug squisher".
> Suggestions, anyone?
>> As a casual developer, and contributor, I would really like to help you 
>> on that. Because it  *is* my problem that the documentation is messy. 
>> But I wouldn't know where to start;
> Dude, all you have to do is *ask*, BOY OH BOY can I tell you where to start :)
>> I can not estimate the time it would 
>> take. A day? it sounds easy, 'package it', but is it easy??. A week? A 
>> day per month for the next 12 months?
> We celebrated the 10 year anniversary of LTSP just a few weeks ago.  I've been
> contributing to Free Software (under it's various appelations) since '85.  I
> just turned 41.  Assuming I live to be 80, and manage to hold onto my wits
> 'till the end, that gives me another 38 or 39 solid *years* of contributions.
>> All I wanted was to get firefox to work as local app and browse the 
>> internet with it. I never compare Free Software to the other kind, for 
>> obvious reasons. I don't expect everything to work. I *want* to 
>> contribute. But it is - even for me with LOTS of Free Software 
>> experience - not something to just do between lunch and noon.
> You are right.  It takes committment.  I'll teach you to edit a wiki.  Once
> you've got that skill, I guarentee editing the wiki *is* something you can do
> between lunch and noon. (We here in Canada tend to take lunch *at* noon, so you
> Canadians out there will have to type while eating).
> Although I addressed my responses to *you*, they're really for *everyone* out
> there:
> You, yes you, reading this out there.
> This software that I write, these docs that I write, these bugs I fix, these
> wiki pages I edit, these emails I respond to, these questions I answer in
> IRC...
> These are *my gifts to you*.
> I've never seen you, or met you, but I care enough about you to take the time
> out of my life, out of my job, away from my family, to help you out, to
> contribute to the greater good.  To *make your life better*.
> But I can't do it alone.  Don't confuse my charity for servitude.  This is
> *your* software.  It's every bit as much yours as it is mine.  YOU need to take
> an active part in this too.  If you want this... this.... *thing*,  this community,
> this Edubuntu to be better, then *you* must step up and add your effort to the
> whole.
> It will take committment.  You'll have to be in it for the long haul.  It'll
> mean (at a minimum) several hours worth of work per month.  It'll mean learning
> new tools, new methods.  You'll have to conform to a group concensus, and maybe
> have to spend time doing things that seem pointless, or busy work.
> But it's all part of the process of making this community.  Nothing worth doing
> is *easy*.  This isn't easy either.
> Good things never are.
> I'll be in #edubuntu, if anyone needs me :)
> Cheers,
> Scott

More information about the edubuntu-users mailing list