14:00:15 #startmeeting Fedora Docs Project 14:00:15 Meeting started Mon Mar 18 14:00:15 2013 UTC. The chair is randomuser`. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:27 * lnovich here 14:00:39 #meetingname docs project agenda - http://fedoraproject.org/wiki/Docs_Project_meetings 14:00:39 The meeting name has been set to 'docs_project_agenda_-_http://fedoraproject.org/wiki/docs_project_meetings' 14:00:51 * jreznik is around 14:00:56 hello 14:00:56 #topic roll call 14:01:01 hello 14:01:09 apparently, I am not good at updating the agenda on the wiki 14:01:13 * pkovar is here 14:01:30 * jjmcd 14:01:30 * Sparks is here. 14:04:36 * bcotton is here 14:05:38 okay, now we can start :) 14:05:45 #chair bcotton sparks 14:05:46 Current chairs: bcotton randomuser` sparks 14:05:53 #topic Action Items 14:06:13 #info we have no declared action items 14:06:24 #topic Docs Infrastructure 14:06:59 I noticed that Publican3 was either in -testing or just koji, and grabbed it 14:07:38 any news about the infra side of this venture? 14:07:47 * Sparks needs to check with Rudi to see if Koji is getting setup for us 14:08:12 want me to ask him sparks? 14:08:52 lnovich: Please do so. He was supposed to be working with... ummm... Kevin? 14:09:02 not Kevin 14:09:04 someone 14:09:17 dgilmore is on the trac ticket 14:09:25 Yes, Dennis 14:09:29 sure - do you have a ticket number? 14:10:03 hi 14:10:31 lnovich: Dennis was waiting on information from Rudi, last I heard. 14:10:38 ok 14:10:49 i will make sure to grab him tomorrow 14:10:49 lnovich, dgilmore needs a list of srpms for docs that we want to be able to build 14:11:00 o 14:11:06 is that all? 14:11:25 thats all i have heard from dennis 14:11:33 do you have a link to the ticket? 14:11:34 that he needs to tell koji to let us build those from SRPM 14:11:36 nb, specific files, or packages 14:11:37 * nb can look 14:11:40 its in releng 14:11:43 randomuser`, SRPMS 14:11:45 packages 14:12:25 https://fedorahosted.org/rel-eng/ticket/5214 14:12:31 thanks 14:13:25 so, all guides? 14:13:33 all *current* guides, anyway 14:14:00 do we need to get members of docs-publishers packager approval for this? 14:14:01 no 14:14:03 All guides 14:14:20 Everything will need to be regenerated and published via SRPM 14:14:34 And, yes, an access list will need to be created. 14:14:58 * randomuser` nods 14:15:26 i'm referring to the sponsor/review process more than the need for an access list 14:16:51 perhaps not, if this is an internal process 14:16:55 Well, I think we can have our own process as we'll not be in the Fedora repos 14:17:54 that'll ease the transition, cool 14:18:42 lnovich, were you also volunteering to add the list of our guides to the trac ticket? 14:20:31 or... can someone do so? 14:21:07 randomuser`: Rudi was doing that 14:21:21 ah, i see 14:21:30 we can move on from that, then 14:21:56 #action lnovich to ping rudi about publishing backend 14:22:14 #topic packaging guides 14:22:34 randomuser i was volunteering to nudge rudi 14:22:52 but what do you want me to do about the ticket? 14:23:25 lnovich, it sounds like a lot of that is pending rudi's input - perhaps just update the ticket with what you learned 14:23:45 ok 14:23:57 someone had an RFI bug out for gnome-shell search integration 14:24:02 is there any other information i need? 14:24:06 pkovar, surprise! any thoughts? 14:25:03 no updates this week. that rfi bug is still open for comments, of course 14:25:21 lnovich, most of our conversations on this end with `rudi is working on it` - i don't know much beyond that 14:25:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=902500 14:25:55 ok 14:26:07 i will give him some guilt 14:26:12 did anyone see the 'knowledge base' app idea on devel@ ? 14:26:28 do you have a link? 14:26:43 sounds interesting 14:26:50 http://lists.fedoraproject.org/pipermail/devel/2013-March/180093.html 14:26:54 ty 14:27:05 I got kind of cranky about it, perhaps unjustly, but there it is 14:27:59 sounds a bit like duplicating what yelp is supposed to do in our default DE 14:28:31 Yelp isn't in all desktops though. 14:28:39 neither would this be i imagine tbh 14:28:45 would this be a mobile app? 14:29:15 lnovich, desktop application is what was proposed 14:29:23 why not mobile? 14:29:56 lnovich, you'd have to ask the proposer ? 14:30:02 ok 14:30:45 i didn't like the idea for mainly one reason: there's going to be a lot more search hits on the ask.fp.o content, and we have no control over the quality of that 14:31:01 good point 14:31:18 did you comment in that thread? 14:31:50 i commented in the thread, and I commented in the ask RFE ticket referred to there as well 14:32:06 great 14:32:09 do you have the link to the ticket? 14:32:30 I asked for admins to curate/verify answers, they told me to +1 them... 14:32:49 in any case, there's the thread 14:32:57 #link https://fedoraproject.org/wiki/Design/Help_Center_Idea 14:33:05 #link http://lists.fedoraproject.org/pipermail/devel/2013-March/180093.html 14:34:01 Please speak up about this idea if you have opinions. I think it's something that's technically easy to accomplish, and might happen because of that, but the result might not be as good as we'd like to put out name on 14:34:08 14:34:29 #topic beat assignments 14:34:53 f19 has been branched; we can start writing our beats more comfortably 14:35:47 will it be pilot tested? 14:36:02 lnovich, can you elaborate? 14:36:46 i mean before it is rolled out - will we have the ability to really look at the application and A. See it truly works and B. See if it lives up to its merits? 14:37:27 Screen shots are nice, but I would like to really test it and see that it gives the predictable answers i would expect 14:37:39 before letting everyone get their hands on t 14:37:40 it 14:38:16 oh, yes 14:38:31 there are alpha and beta releases, of course 14:38:53 and you can use the rawhide instructions with minor modifications to get f19 14:39:10 I'd ask #fedora-qa for specific instructions, not having something at hand 14:39:24 sorry Random user - my points were ment for the previous topic 14:39:59 ahrmm... the koji/publishing topic? 14:40:03 i don't type fast enough before you change the topic... but never mind we can discuss this offline 14:40:33 I like that you have questions about it: afaik, only rudi has these answers 14:40:54 ok let's move on....we'll talk after the meeting 14:41:10 okay 14:41:23 #topic Outstanding BZ tickets 14:41:33 #link http://tinyurl.com/lbrq84 14:41:37 We have bugs! 14:41:45 anyone have a bug they'd like to talk about? 14:44:03 sounds like a no 14:44:12 #topic Open Floor Discussion 14:44:48 guys, did you have a time to take a look on that feature process on docs-list? 14:45:18 there are two questions - how to deal with release notes in feature/change page to make it easier for you 14:45:50 second is - how to pick-up the changes and feature them as features (we changed the process) - for announcements, talking points, etc 14:46:19 jreznik, I think if we enumerated what we'd like to see in a release notes for the devs, it might suffice for #1 14:46:48 ie 1) what does the product do 2) how is it different from before 3) how do I use it 4)where is it documented 14:47:13 with varying levels of detail, as appropriate 14:48:15 i'm hoping someone else has a comment about announcements and talking points... 14:48:24 the email thread started also with RN tracking, RN owners etc. - in a separate process, I think the both could be in one 14:48:50 also one of the ideas is to let devels propose feature early, without details/RNs etc 14:49:09 so it will require more tracking, to have RNs on time 14:49:39 and yes, it's sometimes non-sense to require RNs before the feature is implemented or at least details are known - it works this way now... 14:49:45 * randomuser` nods 14:50:13 honestly, if the other regions of the form are well written, the release notes bit is easy 14:50:59 and a lot of the Features seem to be more brief there than I would actually like, so many will have their content expanded 14:51:55 the changes so far have been very helpful in documenting changes - better writeups on the wiki, the -devel threads especially 14:51:56 randomuser`: that's the reason the RNs are drafted when it's proposed but only a few really updated and extended 14:52:12 so, it's not as if we take the Release Notes section verbatim 14:54:30 well, I'll try to be more concrete in the thread, with some proposals - I'd like to move on with it before the f19 rush starts 14:54:35 randomuser`, I think you list for RN's is a little extensive, except for features that are really new 14:54:57 it seems silly to create a release note for something that conceptually might not even make it into the release, or am I not understanding? 14:55:06 We don't generally need to know what it does or how to use it except for something really new 14:55:34 If we caught all that for updates the RNs would be thousands of pages 14:56:17 What we care about is what changed and what do I need to do 14:56:46 jjmcd, i was thinking more of new products when saying "what does it do" 14:56:52 For a new product, of course we need all that 14:56:59 yep, for a new feature, it makes sense 14:57:09 or something very terse, like "httpd is a web server" and here is what you need to know about the changes 14:57:20 But lots of changes are updates, and if I'm already using it, what do I need todo is more important 14:57:24 randomuser`, yep 14:57:52 i'm sharing my own thought process when writing things - and not expecting the devs to do that work for me 14:58:13 randomuser`, and that is something we need to be more vocal about 14:58:34 I think devs are reluctant to write because they feel like they need polished prose 14:58:34 i just though it may help the devs to know what we want our end product to look like 14:58:58 but then 1) aims more on feature side of thing - means that talking points, announcement... 14:59:28 heh, btw, i pushed release notes to rawhide/f19 that say " there's nothing here, but if you want to give us some raw data to polish..." 14:59:38 randomuser`: < 1 min left 14:59:44 are you all going to be much longer? 14:59:52 jreznik, yes, but we only need to know what is changing/new. Getting the RNs or the announcements into something compelling is not something the dev needs to fret about 15:00:19 randomuser`, +1 15:00:41 the QA team is welcome to ping us about observed changes too - without regard to presentation :) 15:00:55 let's wrap this up, I'm sure they want to start now 15:01:01 #endmeeting