23:00:32 <Sparks> #startmeeting Docs Project Meeting - Agenda: http://fedoraproject.org/wiki/Docs_Project_meetings
23:00:32 <zodbot> Meeting started Wed Jun 23 23:00:32 2010 UTC.  The chair is Sparks. Information about MeetBot at http://wiki.debian.org/MeetBot.
23:00:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
23:00:32 <Sparks> #meetingname Fedora Docs
23:00:32 <Sparks> #topic Roll Call
23:00:32 <zodbot> The meeting name has been set to 'fedora_docs'
23:00:38 * Sparks .
23:00:43 * crantila is here
23:00:46 * rudi_ is here
23:00:47 * jjmcd 
23:00:50 * nathant is here
23:01:01 * quaid is here
23:01:17 * nb 
23:01:53 * Sparks gives everyone a little bit more time to arrive.
23:03:29 * bethlynn is here
23:03:43 <Sparks> Okay, lets get started.
23:04:07 <Sparks> If you have something to say please send a . so I'll know to wait for you.
23:04:22 <Sparks> #topic Follow up on last week's action items
23:04:38 <Sparks> #action rudi and jjmcd to come up with updates to the schedule for F14 release by 30 June 2010.
23:04:47 <Sparks> #action jjmcd to have doc-publican-rpm packaged and submitted for review by 14 July
23:05:00 <jjmcd> List posting should have answered first one, I have a discussion on the schedule, hope everyone has scanned the pdfs
23:05:13 <Sparks> #undo
23:05:13 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b0edc9c4b90>
23:05:15 <Sparks> #undo
23:05:15 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b0edc96cc50>
23:05:16 <jjmcd> d-p-r a little on the back burner until schedule squared away
23:05:35 <rudi_> I still haven't looked at the schedule closely
23:05:39 <Sparks> Okay, we'll talk about the schedule in a bit.
23:06:00 <Sparks> #action jjmcd to have doc-publican-rpm packaged and submitted for review by 14 July
23:06:08 <Sparks> rudi_ to find a solution to present un-translated documents to non-English speakers on docs.fp.o
23:06:22 <Sparks> rudi_: What have you figure out about the untranslated guides?
23:06:25 * Johny_V is here (sorry for being late)
23:06:38 <rudi_> Sparks -- how to present them without making things horrible :)
23:06:48 <rudi_> We still haven't got a solution
23:07:30 <Sparks> rudi_: Is it possible to just have a default of, if nothing then English?
23:07:54 <rudi_> That's only part of the problem
23:08:13 <rudi_> A more complete solution would be "if nothing, then the language that the XML was authored in"
23:08:24 <rudi_> But that's easy anyway
23:08:34 <rudi_> The biggest problem is how to present those docs
23:08:39 <rudi_> Neatly and cleanly
23:08:42 <Sparks> Wouldn't that normally, usually, generally be English?
23:08:58 <rudi_> While still flagging to the reader what that language is
23:09:01 * Sparks was thinking just make them grey...
23:09:07 <jjmcd> rudi_, have you talked that over with mo?  As the UI expert she might have some insight
23:09:20 <rudi_> For Fedora in June 2010, yes, generally true
23:09:36 <rudi_> But not universally true for everyone that's already using Publican
23:09:40 * Sparks was thinking about the quick and dirty for now
23:09:46 <rudi_> and maybe not true for Fedora in the future
23:09:56 <Sparks> rudi_: Understood
23:10:07 <rudi_> Colouring something grey doesn't really tell the user very much about it
23:10:18 <Sparks> rudi_: I also have down for you that you were going to talk about koji
23:10:28 <rudi_> But jjmcd -- yeah, we hadn't thought of involving Mo, so I'll do that this week
23:10:35 <rudi_> Sparks -- yeah, some headway on Koji
23:10:45 <rudi_> I think I've got some minimum requirements worked out
23:10:47 <quaid> +1 on getting UX help
23:11:04 <Sparks> rudi_: Want to wait until a little later in the meeting to talk about this?
23:11:09 <rudi_> But haven't been able to corner the sysadmin who I need to verify the strategy for me.
23:11:13 <rudi_> Sparks -- sure
23:11:18 <Sparks> rudi_: Okay, thanks.
23:11:30 <Sparks> Okay... mine...
23:11:32 <Sparks> Hmmm.
23:11:34 <Sparks> #action Sparks to discuss bug maintenance on the list
23:12:08 <Sparks> #action Sparks Send email to list proposing magazine article work about the guides and docs.fp.o
23:12:24 <Sparks> #info Sparks will talk to Marketing after the meeting.
23:12:39 <Sparks> Okay, anyone have anything else from previous meetings?
23:12:58 <Sparks> #topic Do we still need a CMS?
23:13:13 * nb doesn't see why we do, if we can get publican to build and publish things for us
23:13:46 <Sparks> nb: I think the question, right now, is what would a CMS give us that Publican does not
23:13:52 <jjmcd> nb, part of the Zikula vision was help with workflow, but we still don't understand well enough whether that would be valuable
23:13:52 <nb> yeah
23:14:09 <quaid> framework for a wysiwyg editor for XML
23:14:17 <quaid> but we may not need that if we just put up Beacon + FAS
23:14:23 <jjmcd> Hence,  the investigation bullets
23:14:33 <rudi_> Or Endoculator! :)
23:14:34 <quaid> here's the thing ....
23:14:48 <quaid> we want barriers to be as low as possible, as soon as possible.
23:14:59 <quaid> Docs is a trendsetter here
23:15:02 <jjmcd> Did you see the command line Google docs thing?  That sort of approach might be useful, not that we would want to use Google Docs
23:15:08 <quaid> we were the first to open our CVS to external commiters, etc.
23:15:20 <quaid> so if we can expose our most complex workings so "anyone" can help, that's awesome
23:15:26 <quaid> what is the fastest and best pathway there?
23:15:45 <quaid> jjmcd: I guess I'm thinking opposite of a command line
23:15:51 <Sparks> I THINK the latest developments in Publican have significantly dropped the bar...
23:15:56 <nathant> .
23:16:06 <jjmcd> Well, the thing is, the command like google docs let you use a local editor on remote files
23:16:12 <quaid> hey, all we need is a webapp to trigger builds, and another to do wysiwyg editing, and we've got it (+ FAS)
23:16:15 <jjmcd> s/like/line
23:16:19 <nathant> Learning docbook was a *very* steep learning curve for me
23:16:28 <nathant> still only know the basics!
23:16:28 <quaid> nathant: +1
23:16:49 <jjmcd> nathant, yeah, it is kind of painful
23:16:52 <quaid> jjmcd: only if those CLI utilities allowed local editing with a wyiswyg-style I/O
23:17:03 <quaid> two pieces:
23:17:06 <jjmcd> quaid, that's the thing, it does
23:17:06 <nathant> That doesn't mean that new contributors shouldn't expect to learn new skills
23:17:08 <rudi_> .
23:17:13 <Sparks> A WYISWYG editor isn't going to help if we are still using DocBook
23:17:20 <quaid> 1. wysiwyg editing of XML that is really in source control, not a mock
23:17:20 <Sparks> unless we can fold DocBook into the editor.
23:17:22 <jjmcd> You could use, e.g. gedit, to edit google docs
23:17:32 <quaid> 2. trigger publican builds + FAS auth
23:17:36 <quaid> </>
23:17:36 <jjmcd> Sparks, well, that's emacs isn't it?
23:17:44 <bethlynn> I've been planning on blogging about how awesome it is to be new to the Fedora Project. Is there some place I can (should) document the experience?
23:17:52 <Sparks> jjmcd: Not really
23:17:54 <rudi_> Part of the biggest problem with learning DocBook is a conceptual one -- which tag to use where -- and that it's a semantic markup, not a presentation markup
23:18:08 <rudi_> A WYSIWYG editor doesn't help people over that
23:18:10 <Sparks> jjmcd: You have to learn what all the tags are... and once you do that you can use anything...  OO.o if you like
23:18:15 <Sparks> rudi_: Exactly
23:18:19 <quaid> rudi_: but it does present a limit of options per situation
23:18:36 <jjmcd> rudi_, with the appropriate gui, that shouldn't be much of a barrier tho
23:18:39 <rudi_> sorry quaid, I don't follow...
23:18:39 <quaid> say, inline editing where you highlight a block of text - top 10 choices are going to be pretty common ones
23:18:48 <Sparks> It's not the editor
23:18:49 <jjmcd> quaid, yes
23:18:51 <Sparks> It's the language
23:18:54 <quaid> Beacon?
23:19:12 <jjmcd> Sparks, you don't have to SEE the language directly
23:19:14 <quaid> I've used it to edit DocBook XML
23:19:21 <quaid> after last SoC 2009
23:19:27 <rudi_> Yeah; we need to test out whether something like Beacon would present a lower barrier than editing in a text editor
23:19:41 <quaid> if we test that
23:19:45 <rudi_> Even if it's only a psychological difference, maybe that's enough...
23:19:45 <quaid> what does that give us?
23:19:55 <jjmcd> rudi_, seems like ryanlerch had a gedit addon that came close
23:20:07 <crantila> jjmcd: I was just going to suggest a gedit add-on
23:20:07 <rudi_> Endoculator is awesome :)
23:20:14 <quaid> anyone who wants to do serious Docs work is going to find a way to edit XML locally
23:20:17 <quaid> eventually
23:20:27 <quaid> but the other people, we want to give them a "wiki like" experience
23:20:37 <rudi_> It's not a WYSIWYG, but it certainly allows for rapid prototyping and previewing
23:20:46 * jjmcd finds the wiki a lot more confusing than DocBook
23:21:06 <Sparks> quaid: How does Beacon maintain version control on the source?
23:21:11 <quaid> a web based wysiwyg doesn't have to do more than whatever tags are already in use in a document, most likely -- Beacon has only the subset
23:21:15 * jjmcd looks around for ianweller
23:21:18 <quaid> the subset that we told the developer to put in
23:21:36 <jjmcd> But really, the subset we need is pretty small
23:21:38 <quaid> allow me to remind the group that Beacon was customized to work first and best for this team's specs
23:21:55 <quaid> I was waiting for Zikula, then plugging Beacon in there
23:22:02 <quaid> but it could work standalone if we have a FAS module
23:22:09 <Sparks> quaid: Can you plug Beacon into Drupal?
23:22:13 <quaid> I bet you can
23:22:21 <jjmcd> quaid, that would be coolness
23:22:27 <Sparks> quaid: Can you take this discussion to the list for further development?
23:22:36 <quaid> answer to why Drupal or any other CMS is, we want to give web-based admin tooling to people and not have them work all through Publican.
23:22:37 <jjmcd> Sparks, I'm always worried about performance when someone mentions Drupal
23:22:41 <quaid> Sparks: ok, I'm ready :)
23:23:16 <Sparks> jjmcd: I haven't seen any performance issues in the various setups I'm running
23:23:18 <Sparks> yet
23:23:37 <Sparks> quaid: Thanks... I'd like this discussion to see more eyes because you bring up a very good point.
23:23:38 <jjmcd> I never did locally, either. But live sites always seem slow
23:23:56 <jjmcd> I think it is worth a good discussion on the list
23:24:07 <Sparks> #action quaid to bring to the list a discussion about Beacon and web-based XML editors for Docs use.
23:24:23 <Sparks> Anything else on this before we move on?
23:24:29 <jjmcd> Yeah, get another nick in that to-do list!
23:24:39 <Sparks> heh
23:25:15 * Sparks thinks it has been too long since quaid showed up in a meeting to give us his $0.02 worth.  So now we're getting it $10 at a time!
23:25:17 <quaid> word
23:25:29 <Sparks> #topic Fedora 14 Schedule
23:25:30 <quaid> yeah, summer coding is finally flowing :)
23:25:36 <Sparks> :)
23:25:45 <jjmcd> OK, I assume everyone memorized the Gantt charts
23:25:51 <Sparks> poelcat: You around?
23:26:01 <Sparks> jjmcd: I haven't had a chance to look at them yet but....
23:26:23 <Sparks> did you find anything hideously incorrect?
23:26:30 <jjmcd> On Alpha, I think we should add a notification to devel perhaps 5 days before the first feature page scan, to give them a chance to seed the wiki if they care to
23:26:40 <jjmcd> Nothing hideous, just a few nit-picks
23:26:50 <jjmcd> OK, on beta
23:27:00 <jjmcd> There are a couple of tasks that belong with GA
23:27:22 <jjmcd> But I'm not 100% convinced we have the notification-wiki freeze - convert timing right
23:27:32 <jjmcd> Still want to look at that a little harder
23:27:46 <jjmcd> No real issues with GA
23:27:48 <Sparks> Okay.\
23:27:54 <jjmcd> I think the Guides one is pretty lame
23:28:04 <jjmcd> I was sort of hoping rudi would take point on that
23:28:20 <Sparks> I agree with your assessment that the schedule gets much better with each release
23:28:28 <rudi_> jjmcd -- Yeah, I will
23:28:36 <jjmcd> Yes, as poelcat did it, we could make that work
23:28:46 <jjmcd> But I would still like to see it work better still
23:28:49 <rudi_> I did a plea bargain with Sparks the other week around it ;)
23:28:56 <jjmcd> ;-)
23:29:11 <jjmcd> That's my two cents, I was hoping for other eye/comments
23:29:30 <jjmcd> It can be real hard to recognize disconnects, tho i think breaking it up helps
23:29:36 <Sparks> rudi_: What did I agree to, again?
23:30:18 * Sparks notes that it's not jjmcd or rudi_'s responsibility to check the schedule for problems.  Everyone should be doing it.
23:30:40 <quaid> including Sparks, who asked! ;-P
23:30:46 <Sparks> Yep
23:30:51 <rudi_> I was going to integrate a more robust guides workflow into the schedule; if only I could publish the SMG as a draft rather than a F13 doc with the "Draft" watermark :)
23:31:09 <Sparks> Oh gees
23:31:12 <rudi_> :D
23:31:31 <Sparks> Well, I can tell you that I get thoroughly confused about versioning around releases
23:31:54 <rudi_> Sparks -- yeah, that's one of the main things I need to iron out
23:32:05 * jjmcd has been thinking about that
23:32:26 <Sparks> #action Sparks to discuss document versioning on the list...  when is a doc a certain version?
23:32:57 <Sparks> #link http://poelstra.fedorapeople.org/schedules/f-14/f-14-docs-tree-tasks.html
23:33:21 <jjmcd> Sparks, the pdf's I posted to the list are a LOT easier to follow
23:33:36 <jjmcd> They are simply custom reports from Poecat's source
23:33:53 <Sparks> yes
23:34:29 <jjmcd> If you go to  http://poelstra.fedorapeople.org/schedules/f-14 there is a subdir with the sources
23:34:39 <jjmcd> You can d/l and open them with taskjuggler
23:35:10 <jjmcd> Like he said on the list, it is more like an IDE than a MS Project, tho
23:35:11 * quaid thinking we need to ask poelcat to put that in fedorahosted.org as a git repo
23:35:53 <jjmcd> +1
23:35:56 <Sparks> Okay, anything else?
23:36:06 <quaid> poelcat: you call on me if you want any help on that, k'?
23:36:30 <Sparks> #topic Release Notes
23:36:34 <Sparks> jjmcd: Anything to report?
23:36:37 <quaid> #action quaid will kindly ask poelcat to put up taskjuggler schedule sources in a f'hosted repo, pref. git
23:36:52 <jjmcd> Nothing new on RN's.  Next to-do is clean out the wiki sometime in july
23:37:08 <Sparks> Excellent.
23:37:22 <Sparks> Moving on, then!
23:37:26 <Sparks> #topic Guide Status
23:37:46 <Sparks> I know I said that I would release a schedule for people to talk about their guides...
23:37:58 <Sparks> so everyone would get a chance to speak and we would...
23:38:09 <Sparks> keep up with what everyone else was doing, however...
23:38:17 <Sparks> we now have too many guides!
23:38:39 <jjmcd> What a great problem to have
23:38:40 <Sparks> Discussing two guides per meeting would put us into September!
23:38:45 <Sparks> jjmcd: Ain't it though?
23:38:46 <nb> :)
23:39:11 <nb> rudi_, fyi Oxf13 is around, and may be able to provide comments in how what you have found out so far would work with our existing koji
23:39:17 <Sparks> So I think I'd like to use this time to meet the following needs:
23:39:31 <Sparks> 1) I need help with something in my guide.
23:39:43 <Sparks> 2) I have questions about a guide.
23:39:51 <Sparks> 3) I'd like to find something to work on.
23:40:04 <Sparks> 4) Whatever about this/my guide.
23:40:32 <Sparks> So if you have anything that meets those requirements just step up to the plate and ask away during this time.
23:40:54 <Sparks> We will also use this time to discuss guide-related items.
23:41:04 <Sparks> jjmcd: Would you like to talk about Koji, now?
23:41:27 <jjmcd> Not sure what I can say
23:41:47 * nb thought that was rudi_ that was working on that?
23:41:47 <jjmcd> koji build dist-f13, what more is there to say?
23:41:54 <Sparks> Opps
23:42:03 <Sparks> rudi_: : Would you like to talk about Koji, now?
23:42:19 <rudi_> Yep
23:42:47 <rudi_> So we're talking about two slightly different things here
23:43:13 <rudi_> I'm talking in terms of using Koji to build docs for d.fp.o, not for shipping (necessarily anyway).
23:43:32 <rudi_> We fundamentally need:
23:43:43 <rudi_> 1. a "docs" build target
23:44:05 <rudi_> 2. two tags -- a "docs-stage" tag and a "docs-public" tag
23:44:53 <rudi_> 3. permissions for members of the "docs-writers" group to build packages against the "docs-stage" tag and members of "docs-publishers" to build packages against the "docs-public" tag
23:45:39 <Sparks> This is for automagically building packages of our guides, correct?
23:45:43 <nb> Sparks, yeah
23:45:43 <jjmcd> rudi_, have you been able to reproduce what you want with mock?
23:45:47 <rudi_> 4. some automation on d.fp.o to install new packages as they become available in "docs-public" and for a docs stage to install new packages as they become available in "docs-stage"
23:46:00 <rudi_> Sparks -- yeah
23:46:09 <Sparks> rudi_: There are still problems with how Publican generates the names of these guides.
23:46:15 <rudi_> jjmcd -- I haven't tried
23:46:27 <rudi_> Sparks -- Not for this purpose
23:46:30 <nb> Oxf13, does koji require /cvs/pkgs or can you koji build /cvs/docs/something?
23:46:32 <jjmcd> that would be coolness, tho
23:46:45 <rudi_> We would have those problems if we wanted to ship those packages
23:46:48 <jjmcd> nb, you can do a scratchbuild anyway
23:46:48 <Sparks> rudi_: And a few other items that makes the current packaging command less than perfect
23:47:05 <Sparks> rudi_: So we're building the RPMs and then doing what with them?
23:47:26 <rudi_> Koji builds the RPMs with Publican
23:47:48 <nb> rudi_, so when you do publican --brew or whatever it is, does it make the spec and stuff for koji to use?
23:47:50 <rudi_> Then the docs-stage and/or d.fp.o install those packages
23:47:50 <Oxf13> nb: koji requires that packages live in the packages source control
23:48:05 <Oxf13> nb: our koji won't likely support a way to build directly from upstream source repos
23:48:06 <Sparks> rudi_: Okay so not putting them in the repos, then.
23:48:24 <rudi_> Sparks -- not fedora or fedora-updates, no
23:48:25 <Oxf13> you're going to need a step that migrates the content from the upstream repo into the lookaside cache and dist-cvs repos for the spec file.
23:48:32 <nb> Oxf13, so basically to do something like this, docs would probably have to make a separate koji?
23:48:43 <Oxf13> correct
23:48:44 <rudi_> Oxf13 -- I think Publican can do that
23:48:52 <nb> since you have to be a packager member to commit to /cvs/pkgs
23:49:06 <Sparks> rudi_:  How are people going to get updates when they are available?
23:49:10 <Oxf13> unless you wanted to do just scratch builds, then all you need to do is generate the srpm out of the upstream repo and feed it to /usr/bin/koji
23:49:21 <nb> Oxf13, can anyone use koji build --scratch?
23:49:24 <rudi_> Can we have a /cvs/pkgs/docs ?
23:49:29 <Oxf13> nb: any Fedora packager.
23:49:47 <nb> Oxf13, so you still have to be a member of packager to do scratch builds? or not?
23:49:47 <Oxf13> rudi_: no.  You already have a package module for each package you guys build.
23:49:48 <jjmcd> Oxf13, I did a lot of scratchbuilds without being a packager
23:49:52 <rudi_> Sparks -- which people?
23:50:01 <Oxf13> nb: you have to have a valid cert to interact with koji.
23:50:07 <Sparks> rudi_: the people that get our packages and install them on their computer
23:50:12 <jjmcd> Ahh, yes.  That was required
23:50:13 <rudi_> Oxf13 -- we're talking about a huge number of new packages here
23:50:15 <Oxf13> I think you can get a cert before you're in packager.
23:50:16 <nb> Oxf13, what we are wanting to do is have separate repos for the website to pull from (which might not actually be in fedora)
23:50:20 <rudi_> Sparks -- This process doesn't touch them at all
23:50:31 <jjmcd> Oxf13, yes you can
23:50:31 <Oxf13> nb: then you probably need your own build host
23:50:52 <Sparks> rudi_: So there is no update path so people may not ever get a corrected version of the package.
23:51:23 <rudi_> Sparks -- the only place these packages are going is d.fp.o and docs-stage
23:51:27 <nb> Sparks, we'd have to build it for fedora separately
23:51:29 <jjmcd> Sparks, I thought rudi was talking strictly about docs.fp.o
23:51:38 <rudi_> nb, jjmcd -- yeah
23:51:48 <rudi_> (and an as-yet-does-not-exist docs stage)
23:52:03 <jjmcd> yes, which is also coolness
23:52:19 <Sparks> so people won't be getting these packages from docs.fp.o... this is just for the backend process at docs.fp.o
23:52:22 <nb> rudi_, so we'll probably end up having to amke koji.docs.fedoraproject.org or something
23:52:29 <rudi_> Sparks -- correct
23:52:29 <nb> Sparks, correct
23:52:42 * Sparks isn't quite so confused anymore
23:52:55 <jjmcd> So basically, Publican would make a single-language SRPM, push it to koji or something koji-like, and it would get published to stage or fp.o
23:53:05 <nb> Oxf13, how would that work? would we have to have our own builders and stuff too?
23:53:11 <rudi_> jjmcd -- in a nutshell, yeah
23:53:14 <nb> or can the new koji use the same builders?
23:53:43 <Oxf13> nb: yes, but if all you are building is noarch documents, I think you can just get away with a simple mock setup
23:53:53 <Oxf13> new koji can't use existing builders.
23:53:57 <nb> oh ok
23:53:59 <Oxf13> builders can only build for one hub.
23:54:09 <jjmcd> nb, I'm thinking mock is basically a local koji, so maybe a remote mock on steroids is what we want
23:54:21 <nb> yeah, it'd be really low load (since it'd basically just be running publican build
23:54:25 <nb> and low volume
23:54:25 <rudi_> Oxf13, alternatively, could members of the docs-writers group become packagers limited only to packages for the docs build target?
23:54:47 <nb> rudi_, probably a question for FESCo
23:54:53 * Sparks would like to move on in about a minute so we can stay within our allotted time
23:55:05 <Oxf13> packagers by default don't have access to anything
23:55:07 <rudi_> Yeah; I was asking from a technical PoV, not a policy one...
23:55:09 <Oxf13> they have to be proven packagers
23:55:09 <nb> theoretically it'd be up to the sponsor to decide what the person has to do to become a packager
23:55:26 <Oxf13> so they can become packagers, and you can grant them package access to the docs package modules.
23:55:27 <nb> iirc
23:55:33 <rudi_> OK; we'd need everyone in docs-writers to be able to package
23:55:48 <quaid> +1 to using existing packager methods and systems where possible
23:55:50 <Oxf13> somebody is going to have to sponsor them all.
23:55:50 <nb> Oxf13, would it be possible to make a separate build target that makes a new repo for docs?
23:55:55 <rudi_> And to be able to tag into docs-stage
23:56:00 <quaid> not setting up a shadow system ...
23:56:15 <Oxf13> nb: it's possible, but highly irregular.
23:56:17 * Sparks agrees with quaid
23:56:19 <jjmcd> Oxf13, it isn't like there's dozens, probably <15, maybe <10
23:56:21 <quaid> and it doesn't matter if our packages in Fedora are best tuned for docs.fp.o, others should be able to rebuild from the same packages, and why not in the main repo?
23:56:23 <rudi_> But only members of the docs-publishers group to be able to tag into docs-public (that goes to d.fp.o)
23:56:26 <Oxf13> use of our koji to produce something that isn't Fedora does go against the grain
23:56:35 <rudi_> jjmcd -- LOTs more than that!
23:56:37 <nb> Oxf13, yeah
23:56:45 <jjmcd> rudi_, oh
23:56:47 <nb> Oxf13, i assume it would need to be a question for FESCo?
23:56:52 <Oxf13> yes
23:56:54 <rudi_> About 15 packages per language per release
23:56:55 <Sparks> rudi_ nb: Can you guys take this to the list and bring it back next week for further discussion?
23:56:58 <nb> Sparks, sure
23:57:23 <rudi_> We currently have about 500 packages on d.fp.o
23:57:28 * jjmcd is envsioning rudi recruiting armies of guys who say "mate" a lot
23:57:29 <quaid> nb: yeah, why a separate build target in that discussion plz :)
23:57:42 <Sparks> #action rudi_ and nb to come back with additional information on getting docs-writers building packages in koji for docs.fp.o
23:57:44 <jjmcd> Packages, yes, packagers not so many
23:57:45 <nb> #action rudi_ and nb will discuss this on the list, and then put together a proposal for FESCo
23:57:49 <nb> oops Sparks just did that :)
23:58:10 <rudi_> Cool :)
23:58:12 <Sparks> Okay, anything else before we move on?
23:58:25 <Sparks> #topic Outstanding BZ Tickets
23:58:31 <Sparks> #link https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&classification=Fedora&product=Fedora%20Documentation&bug_status=NEW&bug_status=ASSIGNED
23:58:53 <Sparks> Since we are almost out of time I won't say a lot except to remind people to check your tickets!
23:59:35 <Sparks> I will be bringing to the list, hopefully tonight, a discussion on guidelines for handling tickets in hopes that our readers will keep reporting problems they find.
23:59:43 <Sparks> #topic Open floor discussion
23:59:55 <Sparks> Okay, anyone have anything they'd like to discuss?
00:00:13 * jjmcd notes he is redoing workflow pictures, hopes folks will review and comment
00:00:23 <Johny_V> .
00:00:24 <Sparks> jjmcd: Send them to the list!
00:00:28 <Sparks> Johny_V: Go ahead
00:01:01 <Johny_V> About an issue that you have mentioned and i didn't understand what you exactly mean..
00:01:17 <Sparks> okay
00:01:52 <Johny_V> the topic was Guide Status and the issue: So I think I'd like to use this time to meet the following needs: (and you made a list)
00:02:05 <Johny_V> you moved very quickly and i didn't understand well..
00:02:16 <Sparks> That's fine.  Ask away.
00:02:36 * Sparks notes he should be better on time management in the early portions of the meeting to meet time requirements at the end.
00:02:51 <crantila> Johny_V: that part of the meeting was for people to ask the questions that Sparks listed
00:03:06 <crantila> Johny_V: sparks was not going to ask the questions himself
00:03:18 <crantila> that confused me for a minute
00:03:21 <Sparks> Oh
00:03:22 <Sparks> Sorry
00:03:24 <Sparks> heh
00:03:38 <Johny_V> ok..
00:03:47 <crantila> does that clear it up?
00:04:08 <Johny_V> yes
00:04:14 <Sparks> Yeah, the Guide Status time is for anyone with a question about a guide or anyone with a request for help with their guide to step up and ask
00:04:21 <Sparks> Sorry if that wasn't clear.
00:04:30 <Sparks> Anyone else?
00:04:48 <Johny_V> but you moved very quickly from the issue i mentioned, that's why i asked now..
00:04:49 <jjmcd> Johny_V, often the response is to get a new owner together with someone who can help
00:04:58 <Sparks> I would like to mention that ianweller did a fantastic job implementing wiki translations just the other day!
00:06:22 <Sparks> Anyone have anything else?
00:07:34 <Sparks> Okay, thanks everyone for coming out tonight.  Cocktails in the after the meeting will be served in #fedora-docs.
00:07:39 <Sparks> #endmeeting