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 ? Cheers, ace 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 >> (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 > -- edubuntu-users mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
