14:01:46 #startmeeting Docs Project Meeting - Agenda: https://fedoraproject.org/wiki/Docs_Project_meetings 14:01:46 Meeting started Mon May 20 14:01:46 2013 UTC. The chair is randomuser. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:46 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:01:46 #meetingname Fedora Docs 14:01:46 The meeting name has been set to 'fedora_docs' 14:01:46 #topic Roll Call 14:02:09 Hello 14:02:33 * jjmcd 14:03:47 * LoKoMurdoK here 14:03:47 hmm 14:04:08 * Sparks is here... kinda 14:05:18 HELLO! 14:05:29 hey Nick 14:05:34 hey nb! 14:05:53 okay, we can start now :) 14:06:07 I've actually updated the topic page today: 14:06:13 #link https://fedoraproject.org/wiki/Docs_Project_meetings#20_May_2013 14:06:23 #topic Follow up on last week's action items 14:06:42 I think the only floating action item we had was jjmcd's mail to -devel 14:06:59 And not a huge lot of input on that 14:07:16 * randomuser nods 14:07:27 i was hoping for something more spirited 14:07:54 i didn't send an email, but i think it's a great idea 14:09:03 so, maybe we should just go for it 14:09:03 * lnovich here 14:09:42 #info Docs is considering opening wiki beats up for the next release much earlier 14:10:05 * pkovar is here 14:10:36 jjmcd, one more prod, at least on the docs list, then? 14:10:45 wilco 14:11:05 #action jjmcd to mail about it 14:11:16 #topic Release Notes / Feature Review 14:11:48 So, i think we're moving along fairly well with the RNs, albeit behind schedule 14:12:26 I'd like to spend some time comparing Feature status with how we've represented the features - probably post beta 14:12:55 later, because maintainers are often not so diligent about updating the feature page 14:13:16 jreznik_ has been mailing them about it iirc 14:13:33 So, i'm thinking a VFAD or similar? any thoughts? 14:15:59 #action randomuser to mail list about feature update vfad or similar 14:16:12 I'm not sure how formal a thing a "VFAD" is... 14:16:23 #topic Pushing POTs 14:16:57 Some translators would apparently prefer POTs coming hot and fast 14:17:27 Which would mean more retranslations for the more active groups, but less retranslations for the less active groups 14:18:19 probably most pertinent to RNs, with a rapid change schedule 14:18:45 so, any thoughts on pushing POT changes as they come, vs at release stages? 14:19:37 does the zanata team have a preference? 14:20:42 randomuser: If there was a little box in TX that allowed the translators to say that they were ready for their work to be published then that might go a long way to fixing this problem. 14:20:50 lnovich, i got feedback from one of the guys on the french team 14:21:03 Sparks, :) I haven't forgotten about that 14:21:19 randomuser: Just figured I'd toss that in publicly. :) 14:21:48 #action randomuser to file ticket with transifex re: translators mark docs ready 14:22:24 Sparks: the current workflow is that translators file a bug against the publish request component in rhbz 14:22:56 it's documented in the translation project guidelines 14:23:17 we don't see a whole lot of those bugs, pkovar 14:23:18 pkovar: Right, but those get lost. 14:23:26 ...or not filed 14:23:45 it's sad to see a lang sit at 95% and never get published 14:23:45 sure, having support in tx would probably make it easier 14:23:57 We have a great translation tool. We should leverage that instead of adding more layers, IMO. 14:24:26 or have translation teams publish when they're ready instead of passing it back to the en-US writers to do? 14:24:30 so the idea is to mail the maintainer when translations are ready? 14:24:37 pkovar: In the TX-client there are ways to only download what's x% or certain languages. Perhaps there could be an option to only download what's "ready". 14:24:51 bcotton: +1 14:25:06 yeah, sounds like a good idea 14:25:16 if that workflow works then we shouldn't change it 14:25:17 bcotton: That would be great as well as the translators would see any build errors and could fix them. 14:25:51 who would be responsible for publishing the translations though? only the maintainer? 14:26:19 translator publishing could be easier to swallow as an opt-in thing, like their translation review 14:27:42 pkovar: The translation (lang) team would be the publisher of their language 14:28:15 Sparks: right, that's what i wanted to avoid with our current publishing mechanism 14:28:30 which is too complicated imho 14:28:42 for many translators to learn 14:28:49 pkovar: Seriously? 14:28:57 most seriously 14:29:12 pkovar: I've heard the "it's too hard" arguement before and I will whole-heartily disagree. 14:29:41 pkovar: There is nothing special about Docs people that make it to where we can magically publish this stuff. 14:29:56 pkovar: We have a simple wiki page with step-by-step procedures. 14:30:07 pkovar: In the future it will be even easier. 14:30:33 when we migrate to publican 3 with a new publishing mechanism , then we should probably start thinking how to get translators more "engaged " 14:30:49 Sparks, although, participating 'upstream' isn't something that any other project being translated will ask for 14:30:56 i definitely wouldn't do that before the migration 14:31:25 randomuser: True, but the translators aren't contributing to upstream, really. They are actually creating a derivative work. 14:31:28 also keep in mind that many translators are not as technical as docs maintainers 14:31:44 heh, nice logic 14:31:45 they are less technical 14:31:48 a different group of people, basically 14:32:07 and don't always know what needs translating and what needs to be left as is 14:32:08 pkovar: Hey, if I can do it... 14:32:23 :) 14:32:24 which is why tagging things correctly is key 14:32:52 i just had a whole discussion about how to translate tags 14:33:39 lnovich, if all of us had those kind of discussions, conversations like this one would be easier. We don't always get that kind of involvement from translators 14:33:54 usually, just one or two teams will speak up at all 14:34:16 would you like me to get some opinions or guidelines? 14:34:23 I was thinking of writing someting 14:34:59 tips to writing for a localized world - or something 14:35:19 i can ask the zanata group 14:35:19 I could use those kind of tips, sure 14:35:30 ideally, we'd have a style guide that would tell us what to do for these kinds of things 14:35:31 and get a discussion going 14:35:48 agreed 14:35:51 it sidesteps the process discussion, but involvement is good on all sides 14:36:08 and then come back to the group w/my findings 14:36:11 lnovich, do the zanata people subscribe to trans@fp.o ? 14:36:27 i don't know for sure 14:36:29 i will ask 14:36:40 thanks 14:37:11 NP! 14:37:18 bcotton, wasn't GNOME making the 'one' style guide for us all 14:37:21 ? 14:37:45 * bcotton shrugs 14:38:01 a lot of the style could be combined from various existing sources 14:38:08 Might ping Shaun on that 14:38:49 sounds like something for the off-season 14:38:56 gnome docs team currently doesn't have an updated style guide 14:38:57 would this style guide cover only grammar, spelling, and usage or would it also covered that should and should not be used in defined situations 14:39:27 only a deprecated one from gnome 2 era, fwiw 14:39:27 lnovich, I'd like to have a unified reference for tag usage 14:39:37 i would LOVE that! 14:39:53 there is more than one way to skin the XML cat 14:40:02 and all those ways lead to chaos 14:40:18 Capesteve brought to my attention last week, which avoids all kinds of awkwardness 14:40:44 lnovich: both 14:41:04 I just finished documenting the domain.xml virt initializtion files and figuring out how to describe and define in line was not easy 14:41:25 i mean it is easy but there are at least 5 ways to do it 14:41:31 lnovich, you can ask in #fedora-docs next time :) 14:42:02 so a more "unified" (geez did I say that word?) approach would be refreshing 14:42:18 we've all got the documentation guide cloned, right? 14:42:33 who wants to volunteer to start a section on tag usage 14:42:59 as long as we don't need it tomorrow - I'll take it 14:43:17 can you send me the repo link? 14:43:44 lnovich, no, not tomorrow. Getting the section established for us all to work on is a good enough start 14:43:52 * bcotton notes that this would be a great chapter in the Documentation Guide 14:44:04 +1 14:44:19 ssh://git.fedorahosted.org/docs/documentation-guide.git 14:44:46 and wrapping up the topic, I'm going to go ahead and push POTs as I make changes to the RNs 14:44:53 ok i have no problem putting something together 14:44:58 thanks lnovich 14:45:21 #action lnovich to start section on tag usage standards in documentation guide 14:45:28 #topic Release Announcement 14:45:53 jreznik asked us to talk about the beta release announcement 14:46:05 usually this is a joint venture with marketing and docs, right? 14:47:42 #info if anyone gets a chance, please work on the release announcement 14:47:53 #link https://fedoraproject.org/wiki/F19_Beta_release_announcement 14:48:04 #topic Idea: repo for outlier content 14:48:21 I think we should have a repo for all of the content that doesnt readily fit somewhere else 14:49:00 it would make it easier for new contributors to write up atomic articles, and begin something that might allow us to publish more atomic articles 14:49:20 or, it would store them someplace until a guide writer finds where to integrate a section 14:50:01 any objections? 14:50:41 i think the wiki would be a good fit 14:50:48 then it's more accessible to general users 14:51:12 if the page gets subsumed into a guide, then the wiki page can be marked/cleared as appropriate 14:51:19 bcotton: On the wiki as ASCIIDoc? 14:51:49 right... but this way people can get markup practice and help 14:52:29 and there's a big bucket of unpublished articles for {newsletter, future docs articles} 14:52:35 randomuser: It's more difficult to properly move stuff from one git to a new git (including branches) than to just write it on the wiki 14:52:36 yeah, but if we're writing articles for no one to see, it doesn't strike me as the best use of our time 14:52:57 maybe some of us can be listed somewhere as SMEs for docbook 14:53:12 and then those who need help will know who to turn to 14:53:17 bcotton, that's a fair point 14:53:20 lnovich: Is there a mug for DocBookXML markup? 14:53:38 bcotton: If you want to write stuff that no one will see then definitely put it on the wiki 14:53:39 mug? i have no idea sparks 14:53:41 I was thinking specifically of people that join docs but then they don't know where to start, and guides are intimidating in scope 14:53:54 lnovich: Like the mug with all the emacs commands... :) 14:54:29 ok sparks - let me know if you find one 14:55:20 * randomuser shrugs 14:55:23 not the best idea then 14:55:27 #topic Flock 14:55:37 anyone going to Flock? 14:55:48 will we have a docs presence there? 14:57:30 hmm, might be a bit late in the hour to cover a new conversation 14:57:37 #topic open floor 14:57:49 Last minute concerns and complaints, anyone? 14:58:44 * lnovich im good 14:59:06 Wait, complaints? 14:59:10 * Sparks pulls out his list. 14:59:15 I've been waiting all week for this! 14:59:23 #endmeeting