ltsp local apps + nat + ....

[Ace Suares]

Scott Balneaves wrote:
> 
> 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.

Ubuntu works with launchpad, and I kinda like it. It's interface is 
reasonably nice, a user can really navigate his or her way around the 
site, when there's an action possible or required, it's very clear. The 
best thing that could happen would be that launchpad integrated some 
documentation system. The layout would be more consistent and so on.

Launchpad has also abilities to give permissions to certain parts to 
only certain users or teams. I would roughly envision something like a 
guide or handbook that is kept by the Team - only a few people with 
access - and a part where users can add docs. Then move the user docs 
into the handbook or guide by the team at regular intervals. Much like 
we discussed yesterday on IRC but integrated in launchpad.

In any case, we could restructure the current wiki to have a part where 
it says 'random user provided documentation and then there is where all 
the little tricks go and people would know how to find it from the homepage.

> 
>> 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 must say, using launchpad has been a good experience for me. A not to 
steep learning curve and relatively easy to find your way around it. If 
we have to switch to a new tool, it'd ideally be a launchpad-like thing 
that enables quick addition of docs with a html editor and not a 
wiki-style editing. I am 100% sure that casual contributors know how to 
do a html editor and the wiki treshold is just counterproductive in this 
time and age.

> 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.

It's not really like that, is it?

> 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.

Let's say I have a small addition. For instance my server was running 
XGL for some reason. The TC's must not run XGL. I went onto IRC and 
talked to ogra and he came with a solution right away. It was like one 
line or a flag or an option or such. I tried to program it myself but my 
bash syntax was flawed. Ogra corrected it.

Now how to get that one flag, that one line into the release? Impossible 
for me. I learned bzr, made my own branch, got stuck somewhere, and 
never asked for a merge. Then when I came back to it after a period of 
time, the main branch had changed and i was even more lost. You might 
think it's trivial but to me it's not.

In such cases, it would *really* help if there was a separate task for 
developers to incorporate small changes that are suggested by users, and 
that are for the good of the whole, into the software. For you or ogra 
it would be like 5 minutes work. Saying to such user: yeah, just add it 
to your branch and ask for a merge' simply doesn't work.

In such cases, it *is* necessary for 'someone else to do the work for 
you'. I really wish small changes wouldn't be thrown back to the 
non-developers with a 'use the code, luke' attitude.

The same for documentation. While it's feasible to edit a wiki or some 
other cms and add a small part of documentation, it's not feasible for a 
casual contributor to edit the main document structure and put the 
addition there. I has to be someone with more experience (and maybe 
clearance) that does these smaller things. When not, stuff keeps laying 
around in a wiki-jungle or gets posted to peoples own blogs. It is the 
reason why people post on their own blog some solutions that would go 
better into the main doc tree.

Document Janitor? Code Janitor? Something like that is needed?

>> 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.

And why is that?
Let's say I wanted to add:

opt: no-xgl-on-tc
	load xserver-xorg

which is not even pseudo code but close enough to the syntax of the real 
thing, why wouldnt' I go to ..../code-proposals/new and paste that and 
then be done with it?


> 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. 


It's enough to kick the bug upstream - it's not good that the original 
reporter needs to go to kde.bugs and make an account and then do the 
same dance again. Can that be done? Can a dev kick a bug upstream just 
by clicking a button??
> 
> Or alternatively, someone could pay to have a fulltime "edubuntu bug squisher".
> Suggestions, anyone?

Well, that would be interesting.

> 
> Dude, all you have to do is *ask*, BOY OH BOY can I tell you where to start :)

t'is not really like that, is it? I asked several times now and finally 
I got an answer from LJ, to move stuf from wiki to help. I didn't really 
get an hint from you where to start, did I? Even after I asked? Or did I 
miss it? With all due respect! I still want to help, a concrete and 
clear task would be all I require.

I like the following part. It's inspiring.


> 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
> 

Cheers,
ace