ltsp local apps + nat + ....

[Scott Balneaves]

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 
> (https://bugs.launchpad.net/~acesuares). 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

-- 
Scott L. Balneaves | The dissemination of knowledge is one of the
Systems Department | cornerstones of civilization.
Legal Aid Manitoba |     -- John F. Budd