FDSCo Meeting 2007-08-14 IRC log

[Karsten Wade]

HTML at:

http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Meetings/Minutes/IRCLog20070814

09:03 < quaid> <meeting>
09:03 < quaid> greetings all after a hiatus :)
09:04 < jmbuser> JohnBabich
09:04 < quaid> KarstenWade ?!?
09:05 < quaid> http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Meetings#Agenda
09:05 < quaid> hmm, well, that's somewhat relevant
09:07 < quaid> wow, i'm a bit stimied
09:08 < quaid> I'm literally sitting here trying to figure out what to type
09:09 < quaid> it's not that there isn't anything to discuss, it's that ... well I'm not sure these meetings have much relevancy anymore
09:10 < quaid> I'm having a massive circle of doubt around Fedora Docs
09:10 < quaid> ok, IMO we don't have anything to meet about; 
09:11 < quaid> we don't have enough people for a discussion, nothing to decide, and a large apathy:resource ratio to deal with
09:11 -!- stickster is now known as stickster_work
09:11 < quaid> so I'm going to leave things open here for a few minutes to see if anything has the desire to discuss this right now
09:11 < jmbuser> quaid: We have a great deal to discuss - how to motivate people, for one
09:11  * stickster_work is taking lunch here at desk, back in 5 min. to discuss/bitch/whine/whatever
09:11 < quaid> otherwise, i think we need a serious on-list discussion
09:12 < quaid> jmbuser: I'm getting to be unusually pessimistic about that
09:12 < quaid> as in, how many times can we beat on that horse?
09:12 < jmbuser> quaid: I've been here for a year - a very good year and I'm still motivated - but currently distracted by chaos at work
09:13 < jmbuser> quaid: I see good things happening in the toolchain and in translation
09:13 < jmbuser> Fedora 7 threw us a curve ball with the open-endedness of the application list
09:14 < quaid> well, we are more ambitiuous than we have resources for
09:14 < glezos> quaid, I'm a bit worried about that as well
09:16 < quaid> I feel disapppointed, I gues
09:16 < quaid> we've done a great job of building a scalable project
09:16 < glezos> it's probably OK with Beats/relnotes before each release -- but do we have the resources to follow the wiki -> docbook -> CVS/etc -> publishing for every doc?
09:17 < quaid> but not enough have showed up, and it's all about "the barriers" and "red tape"
09:17 < quaid> glezos: the problem is, we get ~2 people _ever_ who wnt to work in XML
09:17 < glezos> quaid, exactly.
09:17 < quaid> we're adding Plone to that -- plone => docbook => CVS etc.
09:17 < stickster_work> The problem is not the tools, it's the dedication of people to actually get the job done.
09:18 < quaid> does Docs just attract the wrong kind of people?
09:18 < stickster_work> Although there's an argument to be made that the number of tools available makes for fragmenting the workload
09:18 < quaid> those looking for something easier than we present?
09:19 < stickster_work> I don't know how it gets easier when you have people willing to hold hands
09:19 < glezos> stickster_work, I think it's also the tools -- people might be more willing to "just" create a howto/doc in a wiki page
09:19 < stickster_work> glezos: We don't want people to do that, though.
09:19 < stickster_work> We want them to agree to *maintain* it.
09:19 < stickster_work> That's a different level of work commitment.
09:20 < glezos> stickster_work, why not? better nothing than something? We could eventually put a warning on top "this is deprecated" in the worst case
09:20 < ricky> By the way, have you guys started playing with Plone more yet?
09:20 < stickster_work> glezos: That's just multiplying the problem we have now by X number of quasi-contributors
09:20 < glezos> stickster_work, for example, the L10n project would like to update the TQSG with the new stuff, but nobody is doing it because it's too hard
09:20 < ricky> I'm not completely clear on you plan on using it for, I'm just a bit curious.
09:20 < stickster_work> glezos: Actually, noriko is working on that now
09:21 < stickster_work> I was helping her on Friday night
09:21 < stickster_work> ricky: By "you guys," do you mean the ~2.5 of us that are working actively in this project?
09:21 < ricky> Oh..  I guess?
09:22 < glezos> stickster_work, what I want to say is that there is a level of committment various people are willing to take, and docbook/cvs might be too high a step for most of them to take.
09:22 < quaid> ricky: two parts
09:23 < quaid> ricky: to serve fedoraproject.org itself, which is out of the Docs scope but since daMaestro is setting up one instance ...
09:23 < stickster_work> glezos: If we're going to raise a barn together, pretty much everyone needs to commit to hammering, sawing, and hefting.
09:23 < stickster_work> glezos: People who only want to count timbers and fetch water, you only need a couple of 'em ;-)
09:23 < quaid> ricky: for docs.fp.o, Jon is adding a custom workflow that includes outputting to XML into CVS for canonical source and translation.
09:23 < quaid> glezos: I think we have made the Wiki quite available for that level
09:24 < ricky> OK.  I'm not sure about status of fp.o itself at the moment.  Hopefully, there will be a bit more discussion before that happens.
09:24 < quaid> and people do that for other parts of the wiki, I presume; lightweight documentation
09:24 < stickster_work> Right
09:24 < ricky> Hmm..  sounds interesting.  So the final docs would still be generated from DocBook?
09:24 < glezos> stickster_work, so if we don't have the people, then we might need to rethink if we want to raise a barn or just a plain-ol bench under an oak tree. :)
09:24 < quaid> ricky: yes
09:24 < quaid> glezos: that's true, yet ...
09:24 < stickster_work> I'm not interested in bench-building, personally.
09:25 < stickster_work> I can do that on my own.  I'd rather raise a barn with a dozen other people.
09:25 < stickster_work> With the wiki, anyone can "build a bench."  Done.
09:26 < stickster_work> If there's going to be a FDP, we need to commit to barn-building.
09:26 < quaid> +1
09:26 < quaid> that's the point
09:26 < ricky> So basically, people don't want to edit docbook sources directly/translate with po files?
09:26 < glezos> stickster_work, personally, I think our docs infrastructure is already a shiny building I'm proud of. :)
09:26 < quaid> of we are only going to get big enough to build benches, we should dissolve all the hard work and be a SIG
09:27 < stickster_work> ricky: Well, we have plenty of people translating, no problems there as far as I can tell
09:27 < glezos> ricky, translators want to work with PO files, yes. Not with Docbook.
09:27 < quaid> ricky: people want to translate PO files
09:27 < quaid> heh
09:27 < stickster_work> That's a great community, no doubt
09:27 < ricky> So the thing is that people don't like docbook?
09:27 < quaid> ricky: the idea for a while has been to enable multiple $editors with one powerful source in the middle (DocBook)
09:27 < stickster_work> And the community of writers != community of l10n'ers
09:28 < ricky> Aha.
09:28 < quaid> we're actually quite good with that; a guide can be worked entirely in the wiki and output at the end with just a few hours of clean-up
09:28 < ricky> Heh.
09:28 < quaid> now we're adding Plone + Kupu to that
09:28 < quaid> I don't think Docbook is the problem at all
09:28 < quaid> I also don't think it is really the "red tape"
09:29 < quaid> I think it is that we are asking people to be real contributors, not toss-over-the-wallers
09:29 < quaid> and we have the same problem all other tech projects have around docs; "we need that" and "someone else has to do it, i don't have time"
09:30 < glezos> quaid, if we enable people to write docs and maintain them *on the wiki*, do you think the problem won't be solved?
09:30 < quaid> that's right
09:31 < quaid> I don't see where we have told anyone they cannot maintain a doc on the Wiki
09:31 < quaid> in fact, that's what the Docs/ space is for
09:31 < stickster_work> The wiki can accumulate deprecated docs as fast as (or faster than) any other publishing platform
09:31 < glezos> quaid, I think that people won't have a problem maintaining something on the wiki. I'd maintain the TQSG if it was on the wiki to be honest.
09:31 < quaid> we just said, if you want it translated ...
09:31 < quaid> well, my thought is to turn the wiki into a 100% community docs place
09:32 < quaid> and the question then is ...
09:32 < ricky> ^Agreed.
09:32 < quaid> should Docs feel responsible for keeping it clean.
09:32 < quaid> ?
09:32 < quaid> glezos: but how would you get the TQSG translated?
09:32 < stickster_work> ^ +1
09:32 < quaid> do we want 2 more l10n systems (Wiki, Plone)
09:32 < stickster_work> :-P
09:33 < ricky> Not necessarily responsible/high-priority, but it'd be nice :)
09:33 < glezos> quaid, I'd prefer to first worry on how to have up2date content and *then* for l10n
09:33 < ricky> My impression was that l10n was handled after the conversion to docbook (following the normal translation team workflow).
09:33 < quaid> yes
09:34 < quaid> but if a doc is maintained on the wiki ...
09:34 < stickster_work> ricky: The point is that wiki changes happen all the time and every change to a converted doc has to be manually ported in
09:34 < quaid> even if it were automated, it's still hard to track
09:34 < quaid> people don't apply any level of rigor to Wiki work like they do to other work, IME
09:34 < stickster_work> +2
09:34 < quaid> we would have to layer a whole CMS-like system -- 
09:34 < ricky> Does having docs maintained on the wiki somehow increase contributor drive?
09:34 < glezos> My thinking was to have a wiki space where wiki pages are of high-quality in terms of Documentation. They have passed editorial control, they are maintained (names appearing) and if not, there is a warning about it. Lightweight docs as you said.
09:35 < quaid> Docs/
09:35 < quaid> been there for a long time :)
09:35 < ricky> From what I've seen, most projects just have docbook in an SCM, right?
09:35 < quaid> ricky: for example ...
09:35 < stickster_work> We had an initial influx of work for wiki-based docs, but other than the release notes, people have not really done a huge amount of follow-through on drafts
09:35 < quaid> ricky: take the Mozilla Developer site; they changed from XML in CVS to a Wiki
09:36 < quaid> ricky: this was a highly technical group, but they never did their XML work; but in the Wiki, they saw contributions from the community increase 10x
09:36 < ricky> Aha.  So it does help a lot.
09:36 < quaid> so experience shows that people will edit a Wiki, but not maintain there as much
09:37 < quaid> there needs to be people who dedicate themselves to doing janitorial work.
09:37 < quaid> and while that could be this project, to be honest ...
09:37 < quaid> it's not the interest of the active participants
09:37 < quaid> for the most part.
09:37 < ricky> Isn't basic cleanup really easy for bystanders to do on the wiki?
09:37 < quaid> maybe we should advertise for Wiki editors?
09:37 < glezos> quaid, right. We could help people "helping themselves" in maintaining.. Deprecation warnings, categories for obsolete docs, etc.
09:37 < stickster_work> It will be once we get moin 1.6 and the click through CLA in place, right quaid ?
09:37 < quaid> ricky: presuming they know how to write and follow a style guide, yes
09:38 < quaid> stickster_work: well, easier to get people accounts, yes
09:38 < stickster_work> quaid: That's a HUGE presumption too
09:38 < quaid> HUGE
09:39 < quaid> I think after we have Plone up to be a real CMS
09:39 < quaid> we need to reinvent the Wiki
09:39 < quaid> and do some announcemenets around that
09:39 < ricky> I'm personally somewhat afraid of Plone.
09:39 < quaid> which part?
09:40 < quaid> ricky: the reason for Plone is pretty simple
09:40 < quaid> ricky: the process to go from DocBook XML to published pages, no matter how we do it, if it is manual, we'll have about 2.5 people who know how to publish
09:40 < ricky> Well, as a frontend to editing Docbook, I'm not too concerned.
09:40 < quaid> Plone let's us put that in the hands of content area owners, and to automate the XML build so normal folks can edit/publish
09:41 < stickster_work> Best features of both wiki + docbook
09:41 < stickster_work> Easy writing for people who just want to write
09:41 < stickster_work> Toolchain options for other publishing (PDF, RPM, etc.)
09:42 < ricky> For anything something more complex (like a full-blown CMS), it can have a steep learning curve.
09:42 < quaid> well, it's a new Web app to learn
09:42 < glezos> ricky, +1
09:42 < quaid> but you can create documents and edit them with a better WYSIWYG editor than a Wiki is
09:43 < ricky> The GNOME web team has actually been trying to move over to a Plone site..  and it's been painful so far (I saw participation/activity drop down *a lot*).
09:43 < ricky> But as I said, for an editing interface, it might work well :)
09:44 < quaid> well, in terms of just Docs ...
09:44 < quaid> that is, for the Websites side, you see the benefits, right?
09:44 < quaid> I guess for Docs, I can't see how participation can get much lower.
09:45 < ricky> What do you mean about the websites side?
09:46 < quaid> what I mean is, the serving of fedorproject.org front pages
09:46 < quaid> v. having the Wiki be the front page
09:46 < quaid> or having us manually create and maintain pages, or hack up SSIs or whatever
09:47 < ricky> Well, that's where I've seen a lot of pain in other projects.  I'm currently researching any other possibilities.
09:47 < quaid> right now, if you want to delegate some set of pages to a new Websites person, they need a lot experience and access
09:47 < quaid> setup pain?  or maintenance pain?
09:47 < ricky> If you want to maintain clean markup and use kupu, you must know HTML decently (from what I've seen).
09:47 < quaid> I guess the usage of Plone for the front-page was an older idea that is just included with our GSoC work; it can be decoupled, though.
09:48 < quaid> hmm, I haven't edited extensively in Kupu, it just looked like straight XHTML editing.
09:48 < ricky> I don't want to rant on against Plone, but templating for it and customizing page layouts hasn't been easy for me.
09:48 < jmbuser> IMHO, the wiki presentation quality is much improved...thanks to Plone
09:49 < quaid> jmbuser: sorry, where?
09:49 < jmbuser> That's part of the communications process
09:49 < jmbuser> quaid: the main page
09:49 < ricky> Well, maybe it can be modified to remove some of the presentational tags/attributes that it produces.
09:49 < quaid> ricky: well, beat on daMaestro, definitely don't let him get away with an unmaintainable hack for the front-page stuff
09:49 < quaid> jmbuser: main page isn't Plone
09:49 < jmbuser> educate me...
09:49 < EvilBob> HI ALL!
09:49 < quaid> jmbuser: it's just plain HTML + CSS
09:50 < quaid> EvilBob: howdy
09:50 < jmbuser> ahhhh
09:50 < EvilBob> ricky: templating plone is not that hard
09:50  * jmbuser was suffering under a delusion
09:50 < ricky> I don't want to start a war over this, honestly, but I'm hoping to open up the options a bit.
09:50 < quaid> ricky: oh, hardly a war
09:50 < glezos> quaid, do you think plone will increase the number of contributors to docs?
09:51 < ricky> EvilBob: Well, I'm admittedly somewhat pedantic about having "perfectly" clean markup, etc.
09:51 < quaid> ricky: a foregone decision doesn't mean it's locked in stone
09:51 < EvilBob> ricky: http://fedorasolved.org/
09:51 < quaid> glezos: yes, in a few ways
09:51 < quaid> glezos: number of people who can edit/publish can increase easily
09:52 < EvilBob> ricky: make it work first clean it up later
09:52 < quaid> glezos: if people can write with a Web UI editor and have that go directly into l10n and publishing without leaving the Web UI, I reckon that will help
09:53 < EvilBob> ricky: there are many sites out there running plone that most people can not tell are running plone from the outside
09:54 < ricky> EvilBob: Really?  I'd be really interested to hear about some, actually.
09:54  * jmbuser has to cut and run
09:54 < EvilBob> ricky: sure we can hook up later
09:55 < ricky> EvilBob: OK, feel free to PM me if you ever want, or you know where to find me on IRC :)
09:55 -!- jmbuser [n=jmbuser at 195.229.24.83] has quit ["Leaving"]
09:55 < quaid> glezos: esp. if Plone is additive rather than replacing
09:56 < glezos> quaid, agreed.
09:56 < glezos> quaid, if we do manage to have this infrastructure, then it would be great.
09:56 < kanarip> glezos, especially when it doesn't take a year or so to save my doc updates
09:56 < EvilBob> heh
09:56 < EvilBob> wiki pains
09:57  * stickster_work wonders if his planned vfudcon How to Make Docs in CVS is simply a waste of time
09:57  * ricky will probably listen to it :)
09:57 < EvilBob> stickster_work: no
09:57 < EvilBob> not a waste
09:57 < EvilBob> we still need the skills
09:57 < EvilBob> IMO anyhow
09:57 < glezos> Q: do we know of any project (other than wikipedia), that is maintaining high-quality docs on a wiki?
09:58 < ricky> I think he mentioned developer.mozilla.org
09:58 < EvilBob> glezos: a wiki != moinmoin
09:59 < quaid> yes, developer.mozilla.org is one
10:00 < ricky> Anyway, I'm off to lunch now- thanks for taking the time to explain everything to me.
10:00 < ricky> (I'll try to somewhat keep up with the discussion later, hopefully)
10:00 < quaid> we should wrap up
10:00 < quaid> anyone want to add anything more here?
10:01 < quaid> otherwise, we'll continue on-list :)
10:03 < glezos> I'm ok.. sorry if I sounded too negative -- m just trying to think if we are
10:04 < glezos> doing something that could be improved by re-engineering some of our processes.
10:04 < EvilBob> glezos: there has been talk that we are doing more than moinmoin was designed for
10:04 < stickster_work> glezos: You're not offbase... it's just hard to see where the improvement factors come in when there isn't a sufficient sample of where our time is spent on current processes, because there are so few people using them to start with
10:05 < EvilBob> glezos: if that is what you are talking about
10:06 < glezos> agreed :)
10:06 < quaid> ok then ...
10:06 < EvilBob> IMO having to wait for page saves in excess of a minute is ridiculous
10:07 < EvilBob> I don't know where the bottle neck is in that process
10:07 < quaid> it's a design thing, and there has been research into it
10:07 < quaid> Infra has one person who did some tests, etc.
10:08 < vpv> EvilBob: afaik moin goes through all the user accounts to find which ones to notify, rayvd has been working on it, but I haven't heard from him in a while
10:08 < EvilBob> Yeah I know others know about it and have looked at it
10:08 < mmcgrath> EvilBob: Every time you save, moin has to iterate over every user file and every regex in that file to see if that user should be notified about that page.
10:08 < EvilBob> mmcgrath: that is what I thought
10:09 < mmcgrath> we even deleted a bunch of users back in the day (we deleted about 7000 IIRC) and that helpped but it only masked the problem.
10:09 < stickster_work> design--
10:10  * mmcgrath bbiab
10:10 < ricky> Woah.  7000.
10:11 < quaid> yeah, imagine if all those people could edit, scary :)
10:11 < EvilBob> moinmoin was chosen because it met the software requirements IIRC, using python was one of them
10:11 < EvilBob> scalability was not high enough on the requirements list I guess
10:11 < quaid> well, no one knew back then
10:12 < EvilBob> right
10:12 < quaid> and we may be a rather big user of Moin compared to ohers
10:12 < f13> IIRC we're the biggest
10:13 < EvilBob> what works great for a dozen users may not work well for a dozen gross
10:13 < quaid> Fedora contributors -- more than a gross!
10:14 < EvilBob> Yeah
10:14 < ricky> Still >7000, it seems.
10:14 < ricky> Or maybe not.. hmm..
10:15 < EvilBob> I do hope that plone on zope will scale to meet the needs of our contributor and user bases
10:15 < EvilBob> we really don't know until we start throwing stuff at it I guess
10:16 < EvilBob> I have to get back to work
10:16 < EvilBob> BBL
10:16 < ricky> Well, for the docs team, step one would be to get some highly available Plone experts around.
10:21 < quaid> </meeting>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20070815/4700e243/attachment.sig>