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@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>
Attachment:
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
-- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
