FDSCo Meeting 2007-10-21 IRC log

[Bart Couvreur]

19:05 < stickster> <meeting>
19:05 < stickster> Well, we don't seem to have quorum with Dimitris, Bob, and others missing today, but we can do info updates.
19:05 < quaid> ph
19:05 < quaid> oh!
19:06 < quaid> did we reinstate that kind of quorum?
19:06 < stickster> I don't recall we de-instated it, but if you say so, let's forge ahead with hubris
19:06 < quaid> there was a point where we said we could just do stuff and make it revocable just in case :) (to beat the low attendance quorum issue)
19:06 < stickster> OK
19:06 < quaid> k
19:06 < stickster> Ah, neurons triggering
19:06 < stickster> Yes, you're right. I forgot!
19:06 < couf> heh
19:07 < stickster> Let's make like Nike and Just Do It then.
19:07 < stickster> OK, first up is the subject of FedoraUnity.org docs.
19:07 < stickster> We certainly won't turn down properly licensed content, but it has to come with an agreement to maintain it.
19:08 < stickster> Am I right that we are still shying away from "throw it over the wall" docs?
19:08 < stickster> I should note that in the thread, huh...
19:09 < stickster> Hmm... apparently there are no replies other than John Babich's to that thread.
19:09  * couf not completly sure what you mean
19:10 < stickster> couf: Well, having content is good, but what we don't want is for people to hand off a guide and then expect "someone else" to maintain it from then on
19:10 < couf> ah right
19:10 < couf> I would dearly hope that wouldn't be the case
19:10 < stickster> Much better would be, "Here's a guide under an OPL license with no added restrictions, I'll help maintain it, if you help me at the outset"
19:11 < couf> if it would be so, could we just link to there docs?
19:11 < quaid> in general we have more content than people who can maintain it ...
19:11 < quaid> right, what is the advantage of moving it?  as an upstream ... do we need to do anything to it?
19:11 < stickster> I'm not a big fan of having an official docs site that links elsewhere for docs for which we can't enforce standards
19:11 < quaid> if we 'fix' it, why not fix it upstream?
19:11 < stickster> Good point that
19:11 < quaid> is it docs that we can package for Fedora as a downstream?
19:12 < stickster> Still the same maintenance problem though
19:12 < stickster> If we don't want things dumped over the wall here, do we not have the same amount of work by scampering over the wall to maintain docs elsewhere?
19:12 < quaid> welll
19:13 < quaid> what if the upstream adopts our standards?
19:13 < stickster> That would be superb
19:13 < stickster> What's in it for them?
19:13 < quaid> alternately would be to move upstream here, but as you said, maintainers would be needed.
19:14 < quaid> well, it's like being a project that is included in GNOME
19:14 < quaid> you follow GNOME standards, you are on millions of desktops
19:14 < stickster> True, but docs aren't pushed to people individually
19:15 < quaid> sorry?
19:15 < stickster> Well, I just mean that people come and browse a doc on a site, but our standards don't affect the availability of that doc
19:16 < stickster> I think we need to find more of a "win-win"
19:17 < stickster> Joe's "Unofficial DoThis Guide" is going to get juice if people like and swarm "DoThis"
19:17 < stickster> Our standards impose overhead, so where's the impetus for Joe to follow them?
19:18  * stickster is sorta kinda playing devil's advocate, but is more seriously looking for ways to drive traffic and contribution to docs.fp.o for docs that deserve it
19:18  * quaid was thinking of installable docs that might get included in a desktop spin
19:18 < quaid> we follow guidelines that have been established by others because it is easier to make better docs with a common standard
19:19 < quaid> so Joe needs to believe that it is worth the effort. that "good (enough) docs" includes good writing
19:19 < stickster> *btw, by "deserve" I wasn't talking doc quality, more subject matter that merits global inclusion
19:19 < quaid> what subject would we exclude?
19:19 < quaid> ForbiddenItems aside
19:20 < stickster> Well, with a maintainer included, probably not much aside from that
19:20 < stickster> All right, I can see from this that there's a big conversation to be had.
19:21 < stickster> Yet we only had one reply to the original thread.
19:21 < stickster> We should push this back to the list for discussion IMHO
19:22 < EvilBob> Sorry I was AFK making lunch here
19:23 < couf> I'd like to see this cleared, and it seems the list isn't quite discussion-active
19:23  * quaid back from helping his 6-yo find her Secrets of Droon book
19:24 < quaid> sorry I missed on list for this; I can take those thoughts there, s'OK with me
19:24 < stickster> Well, as far as I'm concerned, we'd love to have the docs. I'm sending a reply to the list and cc'ing f-marketing-l asking if someone is interested in rolling up sleeves and maintaining the doc with us
19:24 < quaid> we could set a week to discuss and decide by next Sun?
19:24 < quaid> stickster: +1
19:24 < stickster> If others want to hew to our guidelines, that's not a bad choice either
19:24 < couf> okay
19:24 < stickster> quaid: +1
19:26  * quaid just can't imagine carrying patches to upstream docs ...
19:26 -!- spevack [n=spevack at fedora/mspevack] has quit [Read error: 110 (Connection timed out)]
19:26 < stickster> Ugh, yeah, no fun.
19:26 < couf> oh no, please not
19:26 < stickster> I think best choice is, if it concerns the platform, and someone wants to work on it, we should carry it.
19:27 < stickster> That goes for the most minor tutorial or the biggest guide.
19:27 < stickster> Which brings us very well to topic 2, I think
19:27 < couf> yep
19:27 < quaid> rock
19:27 < stickster> Oh crap, I managed to typo on my topic in the reply I just sent to the list, sorry :-D
19:27 < stickster> So topic two is about carrying howto's.
19:28 < stickster> AIUI what this means is, "If I maintain a smaller tutorial in FDP, can it be listed on the front page of docs.fp.o?"
19:28 < stickster> To which my opinion is, "ABSOLUTELY!"
19:28 < stickster> We still have top docs listed at the top, but there's plenty of room for additional listings here.
19:28 < stickster> I've been thinking we need a redesign in line with the rest of the Project's current web sites, which might make this stuff easier to read
19:29 < couf> right, I'd even tie this in with the "oh we wanted this so long ago"-knowledge base
19:29 < stickster> But all that aside, answer's still "ABSOLUTELY!"
19:29 < stickster> Well, the knowledge base is a separate topic for a number of reasons
19:30 < stickster> (1) Need an engine for this rig
19:30 < stickster> (2) Need a relatively automatable workflow for editing answers so they can be read and translated easily
19:30 < quaid> 2 is part of 1? and I wonder what features we need to decide 1.
19:31 < stickster> quaid: good point
19:31 < stickster> We should look back on previous conversations on the f-docs-l, I'm sure we talked about this before there
19:32 < stickster> And should again, apparently
19:32 < couf> the kb could make the workflow a bit easier for smaller stuff and howto's seem to fit in it
19:32  * stickster would love a KB, makes much easier editing and fast answers for howto/FAQ stuff
19:32 < stickster> But if we're going to have one, needs to be l10n-able
19:33 < stickster> couf: Might make sense to pursue this before we front-burner Training SIG stuff
19:33 < EvilBob> are the software rules still the same, "nothing but snakes on the plane?"
19:33 < couf> stickster: ah good point
19:34 < stickster> EvilBob: What do you mean?
19:34 < stickster> OIC
19:34 < stickster> I'm not sure... I think mmcgrath was considering MediaWiki for the next-gen wiki, but porting is apparently a thorny issue.
19:34 < stickster> That's PHP based, so maybe the rules have softened somewhat.
19:35 < EvilBob> K
19:35 < stickster> But let's try to close the topic at hand -- howto's aren't a problem.
19:36 < stickster> A knowledge base is a larger topic that we should definitely investigate... dig up old conversations, figure out what has changed and how much
19:36 < couf> well as you might've read, there's a new guy in town, who has a whole bunch of howto's and is willing to transfer them to us
19:37 < stickster> Does someone want to volunteer to trawl the archives and bring a new post to the lsit?
19:37 < couf> https://www.redhat.com/archives/fedora-docs-list/2007-October/msg00086.html
19:37  * quaid thinks we should all weigh in on-list a bit
19:37 < couf> stickster: sure, I've been thinking about this for some while now
19:37 < stickster> yeah, "Transfer" sounds fearfully like "Dump"
19:37 < couf> well with the "maintain" part added
19:39 < stickster> Looking at his site, looks like a lot of this work could have been done by him participating in the Desktop User Guide
19:39 < quaid> marc has been around, on/off?, for a while
19:39  * stickster is constantly amazed by how many people persist in "Do It Myself" against the entire philosophy of FOSS
19:39 < EvilBob> quaid: I know marc, he is one of the FU contributors
19:40 < stickster> EvilBob: Why didn't you send him our way earlier, then? :-D
19:40 < EvilBob> stickster: I try
19:40 < quaid> better late than never :)
19:40 < EvilBob> he is not real active, kind of runs in spurts as his class schedules allow
19:40 < stickster> We take all kinds here :-D
19:41 < couf> ow yeah
19:41 < EvilBob> one thing he is very good about is responding to bugs and fixes once he starts a document
19:41 < stickster> All right, so I think it would be really super if John Babich would get with Marc and get as much of his material as is legal and sensible into the DUG
19:41 < EvilBob> so we do not have to worry about things getting dumped IMO
19:42 < stickster> OK, so this is good for list discussion
19:42 < couf> +1 to DUG
19:43 < stickster> I'm composing a reply there
19:44  * stickster encourages Marc and jmbabich to work together on DUG...
19:44 < stickster> I think I remember sending someone else in that direction in the last week too
19:44 < stickster> If people follow through we should actually see some good progress on DUG and AG
19:44 < couf> stickster: yep someone popped up to do some AG writing
19:45 < quaid> which are the two 'umbrella docs'
19:45 < stickster> Awesome!
19:46 < stickster> Well, I added a couple quickies to the agenda --
19:46 < stickster> 3. release notes update
19:46 < stickster> The PO gathering should be tomorrow night according to our schedule, good progress overall but as of now we have fewer complete translations than last cycle.
19:47 < stickster> With a zero-day update that may change, though
19:47 < stickster> The installation guide has a number of translations that appear done too, and thanks to the helpful bug filing of a number of community members there are some real significant improvements in this edition
19:49 < couf> yeah, it's been a bug creating and zapping week
19:49 < stickster> Oops, the second thing I added is silly. Zapped that too :-)
19:50 < stickster> Did anyone have any AOB items?
19:50  * couf has 1
19:50 < stickster> floor is all yours, couf
19:50 < couf> I've been looking into our bugzilla, we've got 103 open bugs there, a lot of which is about old stuff
19:51 < couf> we might want to close a lot of thoose WONTFIX
19:51 < quaid> +1
19:52  * quaid was looking in dismay at his bz home the page the other day...
19:52 < couf> which brings me to: to what extent do we maintain published docs?
19:52 < stickster> couf: Oh, GOOD ONE!
19:52 < stickster> I don't think we have a real policy at this point.
19:52 < couf> indeed
19:53 < couf> or I've missed it while going through the wiki
19:53 < stickster> I think one school of thought would be, we follow Fedora as a whole, so ~13 months
19:53 < stickster> Another would be, deprecate by release, so ~6 months
19:53 < stickster> This is for release-specific docs, right couf?
19:53 < quaid> historically I thought we followed the support for the release overall
19:54 < couf> stickster: yep
19:54 < stickster> quaid: +1, but I can tell you that personally, I can't do it. It's all I can do to keep up with IG and release notes for the most current and upcoming release
19:54 < stickster> (And you could probably argue well that I'm only doing the latter part of that with any success)
19:54 < quaid> stickster: well, let the bugs pile up for the old stuff
19:54 < quaid> good answer to "what can I do to help" :)
19:55 < stickster> +10
19:56 < stickster> So I guess I'd encourage couf to update our wiki with that policy statement, with the caveat that we do this to the extent resources allow... and contributors are always welcome to help with bugzapping for us too :-)
19:58 < quaid> aye
19:58 < stickster> couf: Sound good to you?
19:58 < couf> all right, then I'm done
19:58 < stickster> couf: Bring up a topic, inherit a task :-D
19:58 < couf> something like that yeah :)
19:58 < stickster> The curse and blessing of a volunteer project
19:59 < couf> ow yeah, I'm targetting an intermediate release of the AG the end of next month
19:59 < stickster> SWEET!
19:59 < stickster> When you are ready/willing to port to XML, let me know and I can give you help/pointers
19:59 < EvilBob> what ever happened to us inheriting docs from Red Hat?
19:59 < couf> stickster: I'll hold ya to that :-)
20:01 < stickster> EvilBob: quaid still has his teeth sunk into that AFAIK and won't stop shaking it
20:01  * quaid mumbles nothing aloud
20:01 < stickster> haha
20:01 < quaid> let ya know if anything comes of it
20:02 < stickster> See, we'd love it if they would even just do what the code guys do -- maintain it in Fedora, and branch when they want, adding bonus paid-customer material as desired
20:02 < couf> hell yeah
20:02 < stickster> But this is a very difficult sell because for a long time Red Hat has looked at this stuff as part of the value-add they provide over a community-only distro
20:02 < EvilBob> yeah I would even learn CVS/XML to work on that stuff
20:03 < stickster> In other words, once it's in Fedora under the OPL with no restrictions, nothing prevents JoePublic from scooping it up and rebranding it for his Linux distro.
20:03 < stickster> So the docs become worth less as a value proposition item
20:04 < EvilBob> the CentOS guys are already doing that
20:04 < stickster> On the other hand, you MIGHT get a valuable community of eager contributors to keep up with the day-to-day humdrum of updating how command "xyz" is used, and turn your Content Services people to doing something cooler and worth more to your customers, who as we all know only read documentation as a last resort anyway
20:04 < quaid> EvilBob: nope, the aren't quite
20:04 < quaid> EvilBob: they are doing what OPL says they can do
20:05 < EvilBob> OK
20:05 < couf> copy-paste
20:05 < quaid> right, without rebranding
20:05 < stickster> EvilBob: quaid +1, repackaging the docs verbatim, which is OPL+restrictions-legal
20:05 < f13> and without modifying
20:06 < f13> if there were a more open license anybody could come along and potentially modify/rebrand slightly and publish as their own, with references buried somewhere
20:06 < EvilBob> I have to admit I have seen the docs on their site but always look at the Red Hat version
20:06 < stickster> Ooo, Release Engineering is eavesdropping from on high! :-D
20:06 < f13> heh
20:06 < stickster> Just in case we Docs folks thought no one cared
20:06 < stickster> EvilBob: Yup, so you're seeing the exact same thing then.
20:07 < quaid> f13: but the couldn't have the same logos/branding/TMs on it
20:07 < f13> yeah
20:07 < stickster> Now, if CS moved to a more ETS-like model, there might one day be CentOS docs that say "CentOS"
20:07 < quaid> right, that would probably be exactly and all they would want to do, just rebrand it
20:07 < f13> but in this case the value is in the content itself, not the branding
20:08 < couf> yeah
20:08 < stickster> But surely there are parallels to be drawn between content and code
20:08 < f13> and rh wants that quality content associated with the RH brand
20:09 < stickster> Yup, not arguing that at all.
20:09 < quaid> f13: is this a presumption?  guess?
20:09 < stickster> Well, I think it's an investment of time and people, right?
20:09 < f13> quaid: guestimate.
20:09 < f13> quaid: its the argument /I/ would make.
20:10 < stickster> What happens to CS if a big segment of content is freed, and no one there has any idea of other cool stuff folks should work on instead?
20:10  * quaid would make the same argument that the value is in the code not the branding
20:10 < quaid> but the value for RH is also the QA and etc. they provide beyond the basic content
20:10 < f13> quaid: that is the same argument.
20:10  * stickster is being a little puckish
20:10 < quaid> e.g., we just decided that we don't support docs beyond 13 months, and sketchily beyond release.
20:10 < quaid> while RHEL supports docs as long as the releas (7 years)
20:11 < f13> in the code case, the value is the brand, so if you can associate your bits with a quality brand, you get more attention.
20:11 < quaid> f13: but RHT has already proven that there is a viable business in not holding the code closed ...
20:11 < quaid> f13: so why would we make that argument about content?
20:11 < f13> but in the content case, the value is in the content, so RH wants to attach it's brand to the quality content, and prevent others from doing the same.
20:11 < stickster> f13: I'm pretty sure there are enough differences to be found between Fedora best procedures and RHEL ones that it would support CS working on a RHEL branch of Fedora docs
20:11 < quaid> same could be said for system-config-*
20:11 < f13> quaid: I'm not saying that it's /right/
20:12 < f13> i'm just saying that I can easily see the argument.
20:12 < quaid> I think we argued past that point 2 years ago
20:12 < stickster> All right, we're off on a tangent that we want to pursue, so in an act of final fiat...
20:12 < stickster> </meeting>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dit berichtdeel is digitaal ondertekend
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20071021/46333e7d/attachment.sig>