docs June 2007

docs@lists.stg.fedoraproject.org

39 participants
54 discussions

FDSCo Meeting 2007-06-12 Summary
by Karsten Wade 17 Jun '07

17 Jun '07

Attendees: ----------- Bob Jensen (BobJensen) John Babich (jmbuser) Dimitris Glezos (glezos) Bart Couvreur (couf) Karsten Wade (quaid) Summary: --------- * Jon Steffan is going to ask the list about requirements/RFEs for docs publishing platform * SELinux content needs updating - May push some content upstream for a new home - Paulo Santos (pauolobanon) working on Fedora-specific content * Until we have Plone and Damned Lies alerting us, we need to manually cut inaccurate versions/translations of content * All hands requested to focus on finishing guides individually, one after the other: 1. SMG (split) => UG, AG 2. UG 3. SpinG 4. AG 5. DevelG 6. RPM Guide * FDP is helping with Revisor documentation in two main ways: 1. Help documentation for the new tool (in package) 2. Stand-alone how-to (Fedora Spinning Live Media Guide, or something) * Doc Publishing Platform - Waiting for Plone 3 to deploy - Requirements gathering via f-docs-l * Election discussion in a few weeks; need to keep end-of-July open for making early-August elections happen - Discussion around electing a vice-chair - as done in other projects - useful to split duties - helps train others for leadership

1 0

Interesting Survey Results
by John Babich 17 Jun '07

17 Jun '07

Here are the results of a very interesting survey done by Andy Oram, an editor for O'Reilly Media. "Why Do People Write Free Documentation? Results of a Survey" http://www.onlamp.com/pub/a/onlamp/2007/06/14/why-do-people-write-free-docu… The topic of this survey is people's motivations, not the techniques used. It still is part of the "FOSS way". When we have our "FOSS Docs the FOSS Way" summit, we should definitely invite to participate. John Babich Volunteer, Fedora Docs Project

1 0

BTW Guys
by Mike McGrath 16 Jun '07

16 Jun '07

If I haven't said it in a while. great job: http://fedoraproject.org/awstats/docs/awstats.docs.fedoraproject.org.html Thats a lot of unique users seeing the docs site. -Mike

7 16

Candidate Schedule
by Paul W. Frields 16 Jun '07

16 Jun '07

I've published a candidate for a new documentation release schedule at the wiki: http://fedoraproject.org/wiki/DocsProject/Schedule \=> includes http://fedoraproject.org/wiki/DocsProject/Schedule/8 Comments invited and appreciated. Note that we have about 6 weeks from today to collect info for the first one-sheet release notes. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

2 2

Working, Elegant DocBook to PDF Solution
by Amit 16 Jun '07

16 Jun '07

Hey guys, I applied for a position in the GSoC project for Fedora. The title of the project is "Working, Elegant DocBook to PDF Solution." I was in correspondence with Karsten Wade throughout the application process. However, the last student slot was cut and this project was not chosen. A few days ago, I received an email from Karsten asking me if I was still interested in the project. I was very much interested and thus I am posting my original proposal (abridged - removed some items such as schedules) for the GSoC project here. If the solution sounds viable and applicable, we could definitely get the project going. Thank you for your time, Amit ******************* Application for Summer of Code 2007: Amit Uttamchandani ******** Synopsis ******** I will a propose a solution to convert DocBook XML files into PDF. The approach is a simple three-pronged solution that will focus on simplicity and extensibility. ******* Project ******* The solution involves creating a command line utility to accomplish the task described above. In its simplest form, the utility takes a DocBook XML source and converts into a PDF file. To accomplish this task, I decided to set a criteria for the finished product. ******** Criteria ******** 1. Simple 2. Extensible 3. Standard ************** Implementation ************** The three-pronged approach involves the following: a front-end, a parser and validator, and a PDF toolkit. First, the front end will be based on Python. Python provides a simple yet powerful development environment for implementing our utility. The command line tool would have following interface: docbook2PDF <input>.xml <output>.pdf Second, an XML parser needs to be utilized to parse the DocBook XML source. After studying various implementations, the standard Python XML parser expat is the best choice. Advantages of Expat include its speed in parsing, simple python bindings, and its implementation as a standard python module. Expat, however, does not validate XML files. To validate the XML source, xmlinit will be used. Third, the reportlab open-source toolkit will be used to output the parsed XML data structure into a PDF file. The reportlab toolkit allows for easy output of python data structures into a PDF file. Thus, once a DocBook XML source is parsed and validated, the resulting Python object can then be formatted and outputted to PDF file using reportlab. The above implementation provides a simple, extensible, and standard implementation for the python utility. The solution is based on standard implementation and does not try to over complicate the process. It is extensible because the command-line utility can be easily expanded to include additional options and features. ******** Road map ******** 1. Publish a more detailed description of the implementation and specification, including initial flowcharts and function descriptions to the fedora developers mailing list. Obtain feedback and incorporate suggestions into design. 2. Complete initial version of docbook2PDF utility that successfully validates and parses existing DocBook XML source. 3. Implement reportlab toolkit into docbook2PDF and successfully output parsed XML object into PDF. 4. Thoroughly test the implementation and make sure it meets the requirements and specifications. Write up documentation on usage of the docbook2PDF utility. *************** Future Road map *************** 1. Utility can be extended to batch process DocBook XML files. The utility can be passed a directory and convert all DocBook XML sources it finds into PDF files. 2. A GUI can be added using PyGTK to further extend the functionality of the utility. ********* Biography ********* My name is Amit Uttamchandani and I will be completing my Bachelor's degree in Computer Engineering this Summer at California State University in Northridge. Before my current internship, I had been working for the Information Systems department at the university. During this time, our group was given the task to perform an inventory of all the computers and peripherals such as printers and scanners in the Engineering department. The current tool used at that time was an Excel sheet. I found this to be quite disturbing. The data that we were collecting would be put to much better use if it were stored in a database. The entire engineering department could benefit from this data. Thus, I suggested to implement a web-based solution involving a PHP front end to a MySQL database back end. Now, everyone could input the data virtually from anywhere in a simple and easy to use web front end. Also, predefined queries are available to output the data into a PDF file, complete with charts and graphs. The hidden gem comes with Python and reportlab. As soon as the query is made, a python script was called to retrieve the data from a MySQL database and format it using reportlab and provide a link to the outputted PDF file. This whole process worked seamlessly and allowed our department to analyze how many computers where still using Windows NT or how many computers had less that 256MB of RAM, etc. The above project took 3 months during the summer to complete. The python and reportlab toolkit integration was truly a beauty that shined and impressed. I have been working with reportlab and python ever since to generate on-demand PDF files and reports from databases. I have also worked with Python and XML. I successfully created a Python script 'prop' to parse and propagate XML test case data from one project to another. The implementation used Python and expat to accomplish the task. Implementing this solution took around 3 weeks and the result was a stable utility. By using standard python libraries, I was able to develop using an OpenBSD system and still use the script in a Windows machine. That is beauty of Python. I have been involved with open source software ever since my exposure to Mac OS X. From that point on, I strived to use open source software wherever possible. After sometime I felt the need to return the favor the community and I believe this is an opportunity for me to give something back and be part of the open source ecosystem. *******************

3 4

New POTBASE definition
by Paul W. Frields 15 Jun '07

15 Jun '07

I've updated our Makefile.common with the capacity for a new "POTBASE" variable, in the event that we need the POT file for a module to be differently named from the ${DOCBASE}. This is the case for the following modules: readme readme-burning-isos release-notes These files use an all-caps ${DOCBASE} to generate files in the manner to which RelEng is accustomed. (There may be a point when we change this, but now is not that particular point.) Now our POT files can be named after the module name rather than the ${DOCBASE} which apparently is good for Dimitris and the new L10N WUI. Love all, serve all! -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

1 0

cvsdocs approval
by Jose Manimala 13 Jun '07

13 Jun '07

Hello, i am helping maintain the rpm-guide i need to be added to the CVSDOCS group. can someone please approve me for it. thanks -- Jose M Manimala S6 Computer science and engineering Rajagiri School Of Engineering And Technology Ph: +919846367850 http://www.jmm-blog.co.nr GPGkeyID: 98FF52D2

7 8

Intro
by Scott Dodson 13 Jun '07

13 Jun '07

Hello, My name is Scott Dodson. I live in Raleigh and work as a lab manager for Red Hat. No specific goals or qualifications, just a general geek with free time. I've been building a set of documentation for my own projects and find the Fedora docs to be a great resource. Every now and then I come across outdated pages I wish to update but I've never had an account. So now I've finally signed up for an account. Hopefully as I gain more experience with the documentation work flow I'll find an area to contribute. Cheers, Scott pub 1024D/99A958D8 2007-06-02 fingerprint 835A 0183 B4AC DC48 F606 AC0C 67CD 7973 99A9 58D8

3 2

FDSCo Meeting 2007-06-12 IRC log
by Karsten Wade 12 Jun '07

12 Jun '07

HTML version of this log is at: http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Meetings/Minute… 09:03 < quaid> <meeting> 09:04 < quaid> http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Meetings 09:06 < BobJensen> stale docs... Fresh Docs are better 09:06 < quaid> :) 09:06 < quaid> stickster_work: do you want to kick that off? 09:06 < jmbuser> +1 09:08 < BobJensen> Do we have examples of what does are now stale? 09:08 < glezos> Bob-Laptop: some translations of the TQSG 09:09 < glezos> we haven't found a way to monitor the "expireness" of docs 09:09 < glezos> even with per-release docs like the relnotes 09:10 < BobJensen> Looking at http://docs.fedoraproject.org/ I don't even see our most popular document from what mmcgrath was telling us, "SElinux" 09:13 < glezos> maybe we should create a big, single table with all our docs, their published points and their last updates to help management? 09:14 < jmbuser> for reference only, +1 09:17 < BobJensen> I don't know what to suggest 09:19 -!- |DrJef| [n=onefjef@fedora/Jef] has joined #fedora-docs 09:19 * quaid is finishing a call, sorry he's distracted 09:19 < quaid> done! 09:19 < BobJensen> Do we have examples of what does are now stale? 09:19 < quaid> I think Plone best handle this 09:19 < quaid> or it's not a CMS 09:20 < quaid> but automagic notice? 09:20 < quaid> that's going to require CVS + CMS magic 09:20 < quaid> I recommend ... 09:20 < quaid> when daMaestro asks us onlist for requirements for Plone, we make sure this is there 09:20 < BobJensen> +1 09:20 < quaid> "Automagic notice of when a document is stale with translations" 09:21 < quaid> and maybe automagic changing of an icon "Document trans out of date" 09:22 < BobJensen> Should I call daMaestro and get him in here? 09:22 * couf returns after being called away, sorry 09:22 < quaid> BobJensen: you don't see that document because it hasn't been updated since FC5 09:22 < quaid> BobJensen: I'd like to do it onlist 09:22 < BobJensen> quaid: K 09:23 < BobJensen> quaid: that will help Jon track things also 09:23 < quaid> yep 09:23 * quaid sends that email he forgot to send 09:23 < quaid> yeah, I've already given him crap that I'm going to watch to make sure the RH internship doesn't distract too much :) 09:23 < quaid> right now, afaict, the Plone stuff is the highest priority activity in all of FEdora 09:24 < quaid> but that's just my opinion :) 09:24 < BobJensen> I see a need to get the SElinux Document updated 09:24 < quaid> I emailed dwalsh about it 09:24 < BobJensen> things have changed a lot 09:24 < quaid> he was on the Cc: of my last message 09:25 < couf> yeah, I'm guessing we don't have the real knowlegde to keep that up2date 09:25 < BobJensen> I would be willing to work with Dan to get the SElinux stuff updated 09:25 < quaid> that's the thing 09:25 < quaid> I think we need to reconsider how we do that document 09:25 < quaid> maybe we do need to move the FAQ to the Wiki for now 09:26 < quaid> it would be updated if it had been in the Wiki, because Dan has been working on that 09:26 < BobJensen> Dan's Blog has a ton of stuff in it 09:26 * quaid knows the evils of moving content backward to the Wiki, though 09:26 < couf> quaid: +1 09:26 < jmbuser> BobJensen: There used to be quite a few pundits recommending to turn selinux, which seemed to have prompted many of the searches AFAICT 09:26 < quaid> fucking developers ... 09:26 < jmbuser> s/selinux/selinux off/ 09:26 < quaid> if they would take 1/10th of their blogging time and make it actually part of the project ... 09:27 < quaid> jmbuser: right, and we need clear docs that say why those pundits are wrong :) 09:27 < jmbuser> Now selinux is very stable and is considered a big plus 09:27 < quaid> fwiw, I passed on the maintainership a while ago, and that person has dropped maintaining it, despite nagmails and such 09:28 < quaid> so, the best way from here 09:28 < quaid> is to enable the developers 09:28 < jmbuser> quaid: we should definitely nag the developers to write at least a decent doc which can be improved 09:28 < quaid> or ... push the content upward to the SELinux Wiki and likn there 09:29 < couf> can we link to the selinux faq? http://www.nsa.gov/selinux/info/faq.cfm 09:29 < BobJensen> We need plone 09:29 < BobJensen> period 09:29 < couf> and add some fedora-specifcs in the wiki 09:29 < couf> BobJensen: +1000 09:30 < quaid> couf: that one is useless to users, though 09:30 < BobJensen> on top of that we need plone to do what we need 09:30 < couf> quaid: didn't really check it, came up as top-google search 09:31 < quaid> yeah 09:31 < quaid> http://fedoraproject.org/wiki/SELinux/FAQ 09:31 < quaid> we could dump all of the FC5 FAQ there and ask the Fedora guys to update it 09:31 < quaid> then setup a redirect from docs.fp.o/selinux-faq/.* to go there :) 09:32 < couf> or could we use the RHEL4 SEL Guide? 09:32 < quaid> http://selinuxproject.org/page/Main_Page 09:32 < couf> opening that can again ... 09:32 < quaid> couf: that piece of shit :) 09:32 < BobJensen> yeah those worms are now snakes 09:32 < quaid> also outdated :) 09:32 < couf> hey it's better than nothing 09:32 < quaid> so, the question is ... 09:33 < quaid> does FEdora need a Fedora-specific how-to/FAQ? 09:33 < quaid> or should we donate the content to selinuxproject.org 09:33 < quaid> and redirect all stuff there 09:33 < quaid> that is, isn't SELinux generic enough to not need FEdora-specific stuff? 09:33 < BobJensen> aI think Dan would have to answer that 09:33 < quaid> true dat 09:34 < couf> yeah, we should give Dan some time to anwser and see from then on 09:34 < BobJensen> Having a "fedora" document does have some value IMO 09:34 < quaid> ok 09:35 < BobJensen> When most people search for solutions they are including "fedora" in the query 09:35 < quaid> true dat 09:36 < quaid> ok, dan isn't around, I'll email him separate to get his attention, 09:36 < quaid> ready to finish statle doc discussions? 09:36 < couf> so remove thoose docs (like ol' translations)? 09:36 < BobJensen> plus even if they are using DistroX and they do not include the distro name in the search maybe they find our document and give Fedora a look for their next distro 09:37 < BobJensen> +1 next item 09:38 < quaid> hmm 09:38 < quaid> remove old 09:38 < quaid> tough 09:38 < quaid> sometimes it's not neccesary, since the difference isn't important 09:38 < couf> heh, that's actually the basic question imo 09:38 < quaid> other times it is a big difference 09:38 < quaid> so, case-by-case? 09:38 < couf> yeah 09:39 < quaid> ok, um 09:39 < quaid> do we need to decide here? 09:39 < quaid> or can we discuss and decide on list? 09:39 < couf> I'd say list, could get some translaters attention and make them update 09:39 < quaid> that too 09:40 < quaid> for paul's specific question, I think remove and send email to f-trans-l 09:40 < quaid> ok, moving on ... 09:40 < quaid> so, we need to keep our momentum going with the current guides 09:40 < quaid> is anyone spread too thin to keep their momentum? 09:41 * quaid notices raven updated the TQSG trans for pl today 09:43 < glezos> quaid: translators need to be informed when the POT changes and these POTs should appear on the statistics page so that one can see where his language is lacking, how many strings behind etc. 09:43 < quaid> yep 09:43 < Bob-Laptop> momentum is at a crawl here but you all know that 09:43 < couf> heh that's where you come in glezos :-) 09:44 < couf> momentum is a bit slow here aswell, lot's of daily life, should be better in a week or two 09:44 < couf> when I'll try to get started with the AG 09:45 < quaid> well, we /= just FDSCo 09:46 < Bob-Laptop> BB in 5 09:46 < quaid> for example, jonrob is doing a lot lately, is he spreading himself too thin? should we recommend/ask him to focus on just one guide? 09:46 * quaid picks on jonrob as an example only! 09:47 < couf> aah good point 09:47 * quaid remembers his AOB was "FDSCo elections" 09:47 < quaid> maybe we want a gang-on approach 09:47 < quaid> all gang-on FUG, then all gang-on AG, etc. 09:48 * quaid thinks our TLAs are a bit risque 09:49 < jmbuser> quaid: +1 on concentrated approach - prioritize and conquer one at a time 09:49 < couf> hmm yeah 09:49 < Bob-Laptop> Back 09:50 < quaid> maybe we should 09:50 < quaid> I mean, I could contribute a bit to each guide in series better than in parallel 09:50 < quaid> anyone thing that is a bad approach right now? 09:51 < quaid> or other objections to it? expansions? 09:51 < quaid> I propose these priorities: 09:51 < BobJensen> quaid: I like the team work idea as long as we have a "master editor" to fix things like tone 09:51 < quaid> 1. SMG (split) => UG, AG 09:51 < quaid> 2. UG 09:51 < quaid> 3. AG 09:51 < quaid> sorry,w ait 09:52 < quaid> 3. SpinG 09:52 < quaid> 4. AG 09:52 < quaid> 5. Devel Guide and/or RPM Guide 09:52 < quaid> BobJensen: maybe that is the lead writer's job? and then an editor comes afterward 09:52 < BobJensen> quaid: Sure 09:53 < quaid> ok 09:53 < jmbuser> quaid: Does the editor do the XML conversion? 09:53 < quaid> hmm 09:54 < quaid> jmbuser: I think that is a team effort 09:54 < quaid> jmbuser: since it isn't automated yet 09:54 < quaid> no one is forced to help, but no reason not to :) 09:54 < BobJensen> I have no desire to write anything in the wiki at this point 09:54 < quaid> BobJensen: where do you want to write? 09:55 < BobJensen> quaid: LOL I don't even know 09:55 < BobJensen> I will figure that out and do something 09:56 < quaid> ok 09:56 < quaid> BobJensen: I asked jonrob (iirc) to get with fedoraunity.org to decide where the upstream was for Revisor docs 09:57 < quaid> check out the recent threads there 09:57 < quaid> so we have two separate live media needs 09:57 < quaid> 1. Help document the new GUI tool (revisor) 09:57 < quaid> - these should be the docs that are in the package (/usr/share/doc) 09:58 < quaid> 2. Write a Fedora Spinning Live Media Guide that tells how-to do some common stuff using these tools 09:58 < quaid> - "make a live CD" "make a custom distro" 09:58 < quaid> - 09:58 < quaid> - "make a USB live media that boots and shit" 09:58 < quaid> etc. 09:58 < BobJensen> quaid: Yeah we are a bit slpit on where we want upstream to be, I will force a decision, if they don't have one yet 09:59 < glezos> quaid: the last guide sounds like something that should be written on the wiki rather than on a guide. (freqent changes) 09:59 < couf> for the record +1 on the team effort idea 09:59 < quaid> BobJensen: we're cool with fu being the upstream, from a content view, IMHO 10:00 < quaid> couf: rockin' 10:00 < quaid> glezos: good enough for now, we can make a stub for where the Plone version lives 10:00 < quaid> since Plone has a WYSIWYG HTML editor, there is *no* reason to continue using the Wiki for docs drafting :) 10:00 < glezos> quaid: right. 10:01 < quaid> e.g. docs.fp.o/spinning-live-media/ has a link or a redirect to the Wiki version until we can Plone-ify it 10:01 < couf> hey maybe a sort of round trip, we do the guides, release time (relnotes and IG), we revise the guides again, blabla 10:01 < quaid> couf: yes 10:01 < quaid> couf: I thnk it is working out that way, sort of 10:01 < quaid> while it's nice to have all new content with a release ... well, stuff changes after the release, too 10:01 < quaid> if the community can edit the docs after a release 10:01 < couf> yeah, but this time do everything as team effort 10:02 < quaid> that is, we immediately copy over the old into the new and start updating live 10:02 < quaid> .... with a way to mark that content has been updated 10:02 -!- jmbuser [n=jmbuser(a)195.229.24.83] has quit [Remote closed the connection] 10:02 < quaid> maybe it appears in RED if it hasn't been marked as updated for the latest release :) 10:02 < couf> absolutly 10:02 < quaid> we've hit our hour btw 10:02 < quaid> I can give Plone status in a few lines 10:03 < quaid> I asked Jon to get his requirements list from f-docs-l 10:03 < quaid> we need to heavily participate there, kick out a Wiki page later, etc. 10:03 < quaid> there is lots of existing stuff to work from 10:03 < quaid> he is waiting for Plone 3 release and availability 10:04 < couf> do we need to flesh out workflows etc? 10:04 < quaid> yep 10:04 * quaid pastes in Jon's email 10:04 -!- jmbuser [n=jmbuser(a)195.229.24.83] has joined #fedora-docs 10:04 * quaid pastes in Jon's email 10:04 < quaid> What I need from docs is a feature 10:04 < quaid> list. There are a lot of cool things we could do, but I would like to 10:04 < quaid> just do what we will actually use. Maybe something that would be helpful 10:04 < quaid> for everyone would be an example document workflow. Some example flow 10:04 < quaid> that shows how a document would make it from an end-users keyboard to 10:04 < quaid> our structured documentation platform. Some other things that would be 10:04 < quaid> helpful to me would be a draft of "where" we can edit documents from. 10:04 < quaid> Such, once a document is published to the platform.. does it leave the 10:04 < quaid> wiki (if that is where it was started)? Another question that is more 10:04 < quaid> technical, what VCS back-end are we wanting to use? What document 10:04 < quaid> storage format? Does anyone have any ideas on "states" we can put our 10:04 < quaid> documents into? How many teams will be working on a given document? How 10:04 < quaid> are we going to define roles? Are we going to be able to use FAS2? 10:04 * jmbuser is back 10:04 < quaid> </> 10:04 < couf> jmbuser: topic Plone update 10:04 < quaid> so, I asked him to bounce that to the list 10:05 < quaid> there is a certain amount of that existing under DocsProject/ 10:05 < quaid> and in our brains :) 10:05 < quaid> my only AOB 10:05 < quaid> is to say that it's time to start planning FDSCo elections and sucession stuff 10:05 < couf> Plone update -> list discussion 10:05 < quaid> aye 10:05 < quaid> heads up to those who missed it, RHT appointed me to the Project Board effective 1 July 10:06 < couf> <round of applause> 10:06 < quaid> coincidentally, I had already pledged to *not* run for FDSCo chair 10:06 < quaid> although I'll certainly run for the committee itself 10:06 < jmbuser> quaid: saw it - congrats 10:06 < quaid> thanks :) 10:07 < quaid> so, in the best interests of all, having me out of this seat without too much crossover is a good idea 10:07 < quaid> just so the chair here gets enough focus, which I don't give enough currently 10:07 < quaid> so, that was that, just that we need to pick a date, how about by next meeting? 10:07 < quaid> we can discuss on list as well 10:08 < couf> well yeah, the real elections would be in August-September (Feb + 6) 10:09 < couf> but we could use the intermediate to settle the new chair 10:09 < EvilBob> quaid: So you joining the board will mean that you will be at the next FUDCon, great 10:09 < jmbuser> quaid: Is there a rule for succession? 10:09 < quaid> hmm 10:09 < quaid> couf: oh, that long? 10:10 < quaid> I'm not trying to get out early :) 10:10 < quaid> I was thinking it was end of July 10:10 < EvilBob> the targeted release dates have been suggested 10:11 < quaid> ok 10:11 < quaid> how about we put this topic aside until the end of July 10:11 < quaid> it'll be here before we know it 10:11 < couf> aye 10:11 < EvilBob> I would hope that we would have Aug and Feb Elections 10:11 < quaid> 26 Aug is 6 months 10:11 < quaid> so it should be rolling by mid-August 10:11 < EvilBob> that would put our elections halfway between releases 10:11 < quaid> "Current schedule is the first two weeks in February and August," 10:12 < quaid> that is what the pages say 10:12 < EvilBob> right 10:12 < quaid> http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections 10:12 < couf> jep 10:12 < quaid> yeah, that was the point 10:12 < quaid> sorry, I forgot to read that page before talking it up here 10:12 < quaid> let's talk about this in 30 days 10:12 < quaid> any other bidness? 10:12 < jmbuser> +1 10:13 < EvilBob> If quaid needs/wants us to get a new chair before that I feel we should respect his wishes 10:13 < couf> EvilBob: +1 10:13 < jmbuser> +1 10:13 < glezos> +1 10:14 < EvilBob> the new chair would simply get an extra month or two IMO 10:14 < jmbuser> EvilBob: Is it an election or an appointment? 10:14 < couf> jmbuser: FDSCo decision 10:14 < quaid> true all of that 10:14 < quaid> I wasn't trying to squirm out early 10:14 < EvilBob> jmbuser: we had agreed that the FDSCo would choose their own leader 10:14 < quaid> I can wait 60 days 10:15 < quaid> but if you guys feel my attention is too split, let's fix it 10:15 < quaid> I dunnot yet what FPB is going to mean 10:15 < quaid> it might be the same plus a few additional meetings 10:15 < jmbuser> FDSCo decision is fine by me 10:15 < EvilBob> jmbuser: if someone is inteested perhaps a 2 month co-chair is a solution 10:15 < quaid> another good idea 10:15 < couf> yeah very good 10:15 < EvilBob> a breaking in period if you will 10:16 < couf> have a vice-chair like other-projects 10:16 < quaid> ah, yes 10:16 < quaid> we've gotten away with not doing that because, erm, RHT pays me to be on IRC during my work hours :) 10:16 < jmbuser> +1 10:16 < quaid> but it's not really fair to anyone, IMHO 10:17 < quaid> ok, steady on 10:17 < quaid> if there is nothing else ... 10:17 < EvilBob> rather than tabling this for a month how about we think on it for two weeks and adress ideas then 10:17 < EvilBob> a month is a long time 10:17 < couf> EvilBob: +1 10:18 < glezos> quaid: I've put up some issues concerning our docs source structure, but these could be discussed on-list 10:18 < EvilBob> if anyone is interested in being the new chair bring your resume to that meeting in two weeks 10:19 < EvilBob> Motion to close the meeting? 10:19 < couf> coolness 10:20 < quaid> EvilBob: good call 10:20 < couf> +1 10:20 < jmbuser> +1 10:20 * quaid notes for the Brits in the audience, "tabling" is being used in the American vernacular, "to put aside for discussion later" 10:21 < quaid> where in the Brit vernacular, 'tabling' means "to put the idea on the table right now for discussion" 10:21 < quaid> OK! 10:21 < EvilBob> interesting 10:21 < quaid> EvilBob: yeah, one of my favorites because of how (in)obvious it is 10:21 < quaid> more? 10:21 < quaid> no mas? 10:21 < couf> nope, close away 10:21 < quaid> deal 10:21 < quaid> 5 10:21 < quaid> 4 10:21 < EvilBob> wrap it up boss 10:21 < quaid> 3 10:21 < quaid> 2 10:21 < quaid> 1 10:21 < quaid> <tradition/> 10:21 < EvilBob> Happy New Year! 10:22 < quaid> </meeting>

1 0

Questions regarding my man/info summer project
by Ville-Pekka Vainio 12 Jun '07

12 Jun '07

Hi, (I'm CCing fedora-docs-list and Ivana Varekova who seems to maintain Fedora's man-pages package, I hope that's ok) As some of you may have noticed already, I'm working on a summer coding project that's about man/info page publication and editing with MoinMoin. There's a more detailed description here: <http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio> I've hit a problem now and I'd like to get your feedback, I assume there are some people here who maintain man or info pages with their software. The problem is choosing the correct storage format for the man/info pages in MoinMoin. Publication of those pages is relatively simple, but editing them and getting the edits upstream is a completely other thing. For brevity, I'll be talking about man pages here only. It's possible to store the man pages "as such" (as described in man.7) and then display them through a Moin parser. But then users editing the pages through the wiki would have to know *roff, which probably isn't very newbie friendly. On the other hand, Moin would generate "upstream compatible" patches from the edits (almost) automatically. Another possiblity is to store the man pages in wiki markup. That would be very easy for the users to edit, as they probably already know it and it's simple. But how to get the changes upstream then? A wiki markup -> man source exporter would be possible to make, but it's probable that the man source generated automatically from the wiki markup would differ a lot from the original upstream man page source. So producing meaningful and clean patches that could be easily applied would be difficult this way. The main question here concerning this whole project is: what do we want from the project? Do we want the system to be an information source to man page maintainers ("this man page could have these points") where they could take material from and then add it to the corresponding man pages themselves? Or do we want the system to be a tool for the maintainers where they just take patches from and apply them with minimal human interaction? Of course the latter sounds better, but it's also a lot more difficult to implement. That's why I'd want some feedback from those who maintain man/info pages for their projects. If the system only produced wiki markup or plain text diffs, would you still incorporate the changes into your man pages (assuming they are reasonable content-wise)? Also, how would you maintainers describe your workflow when it comes to updating man pages? Do you usually get ideas from users and if so, how do you incorporate them into your man pages? Or are the man pages usually written by the same individual who maintains that specific piece of code? Even though it seems that the main "audience" for this system would be the users and administrators, it definitely wouldn't hurt if it helped the developers/maintainers in their work too :) Thanks in advance for your input! -- Ville-Pekka Vainio vpivaini(a)cs.helsinki.fi

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs June 2007