FDSCo Meeting 2007-06-12 Summary
by Karsten Wade
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
16 years, 9 months
Interesting Survey Results
by John Babich
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-do...
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
16 years, 9 months
Working, Elegant DocBook to PDF Solution
by Amit
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.
*******************
16 years, 9 months
New POTBASE definition
by Paul W. Frields
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
16 years, 9 months
cvsdocs approval
by Jose Manimala
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
16 years, 9 months
Intro
by Scott Dodson
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
16 years, 9 months
FDSCo Meeting 2007-06-12 IRC log
by Karsten Wade
HTML version of this log is at:
http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Meetings/Minu...
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>
16 years, 9 months
Questions regarding my man/info summer project
by Ville-Pekka Vainio
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
16 years, 9 months