ltsp local apps + nat + ....
ace at suares.an
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
> 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.
>> 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
> 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
> 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
> 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 :)
More information about the edubuntu-users