Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=450331
Summary: lack of documentation on restoring from bare-metal (UUID
problem)
Product: Fedora Documentation
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: docs-requests
AssignedTo: kwade(a)redhat.com
ReportedBy: czar(a)acm.org
QAContact: stickster(a)gmail.com
CC: fedora-docs-list(a)redhat.com
Description of problem:
ref: https://bugzilla.redhat.com/show_bug.cgi?id=449299
There is a lack of documentation on restoring a system from bare metal. I have
found (see reference) that restore the root ("/") is not as simple as as just
executing the restore command when running in rescue mode.
With the current emphasis being place on use of UUIDs in both Fedora and RHEL,
the whole business of UUIDs need to be better documented.
Version-Release number of selected component (if applicable):
Fedora 9
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Direct links to RNs broken.
https://bugzilla.redhat.com/show_bug.cgi?id=595695
Summary: Direct links to RNs broken.
Product: Fedora Documentation
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: docs-requests
AssignedTo: eric(a)christensenplace.us
ReportedBy: eric(a)christensenplace.us
QAContact: fedora-docs-list(a)redhat.com
CC: stickster(a)gmail.com, kwade(a)redhat.com
Classification: Fedora
Description of problem:
* Previously, the release notes were located at
http://docs.fedoraproject.org/release-notes/
* Their location has changed to release specific URLs.
* A link to the release notes is provided in fedora-bookmarks.
* fedora-bookmarks are imported by the browser only on *first launch* so as to
not overwrite user modifications.
The new bookmarks layout causes two problems:
1. Nobody filed a fedora-bookmarks bug so Fedora 13 (and anyone on F-11 or F-12
etc) will default to going to http://docs.fedoraproject.org/release-notes/
which is a 404. Since the bookmarks can only be imported on first launch, we
cannot push an update to fix this if the user has launched the browser (which
is extremely likely).
2. Even if I were to fix the bookmarks page to point directly to a specific
release version (which again would take effect only if someone would yum update
before launching Firefox), then if anyone updated to F-14, the bookmark would
not change and would still point to e.g. F-13.
So, I do not think that we should put version specific information into our
bookmarks URLs. To solve both of the above problems, I believe we should try to
do some User-Agent detection and redirection. Fedora browsers have an RPM NVR
attached to them.
For example:
Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.2.4) Gecko/20100517
Fedora/3.6.4-1.fc13 Firefox/3.6.4
This tells us that the user's installed language is es-ES and it's a Fedora
browser, specifically running F-13. We should then redirect queries to
http://docs.fedoraproject.org/release-notes/ to
http://docs.fedoraproject.org/es-ES/Fedora/13/html/Release_Notes/index.html
If we cannot figure any information out about the Fedora release or language
(or there are no relnotes in that language), I propose the default redirect
should be to the en-US version of the latest Fedora release notes.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: CMS for docs.fp.orghttps://bugzilla.redhat.com/show_bug.cgi?id=504066
Summary: CMS for docs.fp.org
Product: Fedora Documentation
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: project-tracking
AssignedTo: kwade(a)redhat.com
ReportedBy: mel(a)redhat.com
QAContact: kwade(a)redhat.com
CC: fedora-docs-list(a)redhat.com
Classification: Fedora
Zikula chosen, working on test instances and project plan with Zikula team
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: SRPMs fail to build in Koji
https://bugzilla.redhat.com/show_bug.cgi?id=513907
Summary: SRPMs fail to build in Koji
Product: Fedora
Version: 11
Platform: All
OS/Version: Linux
Status: NEW
Severity: urgent
Priority: high
Component: publican
AssignedTo: jfearn(a)redhat.com
ReportedBy: eric(a)christensenplace.us
QAContact: extras-qa(a)fedoraproject.org
CC: jfearn(a)redhat.com, fedora-docs-list(a)redhat.com,
mmcallis(a)redhat.com
Classification: Fedora
Description of problem: SRPMs fail to build in Koji due to the following error:
Processing files: fedora-security-guide-en-US-1.0-16.fc12.noarch
error: Two files on one line: /usr/share/applications/Fedora
error: File must begin with "/": Projectfedora-security-guide-en-US.desktop
Version-Release number of selected component (if applicable): 0.44-0.fc11
Possible Fix: Remove the %{?vendoropt} from
desktop-file-install %{?vendoropt}
--dir=${RPM_BUILD_ROOT}%{_datadir}/applications %{name}.desktop
or remove %{vendor} all together.
I'll be testing this soon to see if I can provide a patch.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Publican migration
https://bugzilla.redhat.com/show_bug.cgi?id=504064
Summary: Publican migration
Product: Fedora Documentation
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: project-tracking
AssignedTo: kwade(a)redhat.com
ReportedBy: mel(a)redhat.com
QAContact: kwade(a)redhat.com
CC: fedora-docs-list(a)redhat.com
Classification: Fedora
Figure out steps for a migration of each guide; track that in each guide's
Trac. Installation Guide migration branch in git; task in progress, possible
work at http://fedoraproject.org/wiki/FedoraEvents/FAD/FAD_SCaLE
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Toolchain next steps
https://bugzilla.redhat.com/show_bug.cgi?id=504063
Summary: Toolchain next steps
Product: Fedora Documentation
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: project-tracking
AssignedTo: kwade(a)redhat.com
ReportedBy: mel(a)redhat.com
QAContact: kwade(a)redhat.com
CC: fedora-docs-list(a)redhat.com
Classification: Fedora
Sorting out what fedora-doc-utils does, where to use Publican, etc. --
Principals to discuss status, progress, direction on IRC.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
One of my tasks has been to review the schedule. Of course, we all
should be looking at it. I've been struggling some to make sense of it.
There are a couple of issues, but even a few issues can make it very
confusing.
You should all be aware that John has posted the schedule at
http://poelstra.fedorapeople.org/schedules/f-14/
If you look at f-14-docs-tasks.html it can be very confusing since
release notes, announcements and guides tasks are all mixed together.
The report, f-14-docs-tree-tasks.html is a lot easier to digest. Until
you have your head around that one, the docs combined with translation
and releng are totally confusing, so look at the tree tasks first.
It is a pity that you don't seem to be able to get a Gantt chart out of
taskjuggler, but if you download the two files from John's "source"
directory (f-14.tjp and reports.tji) and open them up in taskjuggler,
you can see the dependencies in the source. To do that:
1) Select the tasks tab on the left
2) Highlight the task you wish to examine (note that in general
the tasks are folded into higher level tasks)
3) The task will be highlighted in the source on the right, and
if there is a dependency, it will say "depends" on the right
under the highlighted task name
It still isn't super-simple since Docs is only a tiny part of the whole
release, and of the hundreds of "external to docs" tasks, there are
perhaps a dozen that actually matter to us directly, and they don't
always show up within the folded group (e.g. Beta Release Notes), so it
isn't always obvious why a particular task has to happen on a particular
day without a fair amount of digging.
Rudi and I will be getting updates to John, so if you notice anything
that seems out of place please let us know.
Thanks,
--McD
One of the wiki pages identified as "needing love" was the one
documenting the workflow we use:
https://fedoraproject.org/wiki/Docs_Project_workflow
I've made a start at updating that, trying to be a bit more graphical.
(OK, I'm an engineer; I tend not to read the manual but I do look at the
pictures!)
We definitely need more detail underneath this, but I would like some
feedback on whether this is a helpful approach. All of the old
material, some of it badly out of date, is still there but commented
out.
Some of the things I thing we need:
- Guidance on editing the wiki
- Guidance on applying for groups
- Guidance on conversion to XML, both manual and via the python tool
- Howto XML -> Publican -> docs.fp.o
Probably lots of others.
Any feedback appreciated.
--McD
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Need to package OpenWYSIWYG
https://bugzilla.redhat.com/show_bug.cgi?id=516794
Summary: Need to package OpenWYSIWYG
Product: Fedora Documentation
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: high
Priority: high
Component: project-tracking
AssignedTo: fedora-docs-list(a)redhat.com
ReportedBy: eric(a)christensenplace.us
QAContact: eric(a)christensenplace.us
CC: stickster(a)gmail.com
Blocks: 504066
Classification: Fedora
Download: http://code.zikula.org/scribite/downloads
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Need to package FCKeditor
https://bugzilla.redhat.com/show_bug.cgi?id=516793
Summary: Need to package FCKeditor
Product: Fedora Documentation
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: high
Priority: high
Component: project-tracking
AssignedTo: fedora-docs-list(a)redhat.com
ReportedBy: eric(a)christensenplace.us
QAContact: eric(a)christensenplace.us
CC: stickster(a)gmail.com
Blocks: 504066
Classification: Fedora
Download: http://code.zikula.org/scribite/downloads
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
I was looking for the F13 install guide at the new docs site [1] but,
as there is no Spanish version yet, the site seems to indicate that
there is no install-guide at all [2].
Is it possible to have at the left the links to the English version
for the untranslated books?
So the Fedora documetation list is complete. New users will see
untranslated guides in English and would probably want to join us in
the translation efforts.
What do other language coordinators think?
[1] http://docs.fedoraproject.org/
[2] http://docs.fedoraproject.org/es-ES/index.html
kind regards
Domingo Becker
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So at what point does a guide go from F12 to F13 to F14?
Is a mid-cycle released guide the current version (F13) or is it draft
if the guide isn't complete but is relevant to the current release?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMIsTFAAoJEDbiLlqcYamxlFMQALFq9aT+4cdQwo6LdBDNq74a
QrSRQ/5b4reXSNmMdq5zxaQ6UQ6xKVNbvOhh98u/7+YiRTSg9plmcuIZrquJf3kH
wjeZ5SrygdVoEy+94RTi6x3BKXsMrSt6oYMKWt4TetXWbmo5Emb6L8TQWFlwy9e4
OXaGmjBDsHoW0+acDn80xHfzLZgLWoGF33UaJPHY0UFGj8m4yymXUn+iuyukZjzU
eSg4RR7GwUrwcoS3CVkWDGc9W6AxhqLPK5YpNVUk8w+mwOiNYuEbX617gKViLjty
kUr7IOQI5NGFRy+U2bOYyblkACVr1dEXaD9Qx2bIb5Zluo9M7gcPnxZCJ4CM3Suj
6+k5o6v0p7wUwBoEgT2o5CyopSiZc09MJwBNzmn0UhCPsJP7/2b9lktcEI9ADTGq
VyXI7eNOS4cr2HvOgZv+UO+Y5+MiidMddaozHE+Vk+UM51DKhRv+8GbBbm/fCwah
3Ympsdri5EbnlSH1idEB2NMr/6z9yXf7/mDbtG5BSp4wBJU4IQHRBKmq+ewbYKSe
5ikdXSi2DWAPsCxP51ov2GtJNUj4KmRolqNGetTdtzprU32T/K7HB9tiFYIspwnA
gour5/BqgA3PF4nCrywIDn0Lzaa42V78GOsjiJLWwzgUFd6yY7kXbHztKSOiPZOi
8qPTRVaWGgVLGLePzENw
=xD1H
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
REMINDER: There will be a Fedora Docs Meeting today at 2300 UTC. The
agenda can be found at:
http://fedoraproject.org/wiki/Docs_Project_meetings#Agenda_for_Next_Meeting
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMK2eYAAoJEDbiLlqcYamxyIkP/358hFz+JbVvLlzCL4Cjsf4J
jz6/QbEIRGAJFg7wzRQLVtxQIqZCpz22NGzFkFSZzOCm3T0nJ9vmEK+OlD/ss7Nq
Kxh0/eEWQqUSXoW2g6zHG1iT31T4hmCql8oBIpcQ8BVkYfjBLvChP9ap97RPh3cu
xuRliS2M6hTEqh+5ocoShfKv3+nrlx0JHSXCSSAbIIvtY+zekLgb5dXp3PNI0SLr
EBDTArbw3cts0AyrA2gRpGsM1pD/fk0G/xvGiEaw73q+1PuQ1V+q8Cjgel3Lmyne
Em2ixHDrUhrxmjRgmiV1Z+KBD2OWD2Dep9QqUJHb7E1KFW6ujlivFOoq8XmJ+EEa
gK2BeB0NATy0VfVych4rVTYpNotMu3lK65l4agiFgt3YeD/79FBC1Bux/EVqIykj
iiIxKp7XjZ1yK/rMq8OQbyfp7LCiwaarnKT4PhYE2Qac66NiZ97R/mEcXK9a7qUY
SjDOaUHa7TyAQZUBebyQ/sswyXgYDUICc75r2kFmp1P+wodrRE+8++hG8VsF9DWa
Z5FcDte6nYM8qglZNTfiKRAaHgVpCe8xhEjZAJItPrlg+/E5mB0SE9u0e03huNa5
C/oTCA2Yd9XQxoE3T0FVFJ5trRvabmFspR0M1ZoKnngKztIMdcavRKqyvEeuEn/9
fKtLrkvQRNBAfL4xLT+O
=YoVv
-----END PGP SIGNATURE-----
Hello:
I have some comments about the (G)UI aspect of the CMS ideas floating
around. Imagine that everything following is prefixed with the "in my
experience," "in my opinion," or "as a new/prospective docs
contributor," warning.
Quaid:
>While Publican gives us a way to build a nicely organized tree of
>content, it doesn't give other capabilities. I don't know of any
>plans to include this sort of thing in Publican natively:
>* Ability to trigger (re)builds from source repositories via a webUI.
>* Workflow control, either by group (writers, editors, publishers), or
> specific roles like that but per document (I can write this one, I
> can edit yours, and I can push hers to publish after you edit it.)
>* WYSIWYG editor for DocBook XML from source repository.
Having to learn fifteen (or even three) completely different programs
before being able to contribute is discouraging. It's also somewhat
irrelevant how difficult it is to learn those programs, because new
contributors are going to be afraid of making mistakes.
Quaid:
>Basically, we still have very high barriers to move from "edit stuff
>on the wiki" to "manage a full guide on DocBook XML." The main
>purpose for a CMS is to get the ability to publish and tweak
>docs.fedoraproject.org out of the hands of a very few, very busy
>people, and in to the hands of just about anyone that this team wants
>to authorize to do work there.
That barrier is very real. If you want something that will allow a lot
of people to contribute to the publishing effort, then it's going to
have to be easy. Furthermore, technical barriers should only exist for
things actually related to the writing process. That is to say, the
fact that I don't already know how to use git shouldn't stop be from
contributing to a guide - it should be the fact that I don't already
know the program I'm going to write about.
Quaid:
>This proposal exists partially because of our commitment to using
>Publican to publish.
I ask this out of ignorance for the docs process and without any real
idea of what Publican is or what it does: why are we using it? I'm sure
there's a good reason, but "But we're using Publican!" seems to be the
reason that Docs doesn't already have a CMS.
Quaid:
>Functions:
> ...
>0. Read
What we do here has to look good, and it has to be easy to use. I'm
tempted to say that this particular aspect of the documentation process
shouldn't be left to the Docs team at all. Writers of documents should
be focussed on the content of those documents. Leave all the
typesetting and other business to people who are focussed on that. Docs
could bring in (or maybe already has) some people focussed on this, but
maybe another Fedora SIG is better-suited to document presentation than
Docs is.
I would personally at least like to see visual integration with the rest
of the Fedora Project website. Currently the docs website is one of the
many confusing sub-worlds of FP, and it looks, frankly, cold and unhelpful.
More importantly, it must be easy to use. The new Docs website is
definitely an improvement over the old one, but it still doesn't answer
questions that I ask of it quite often, like:
1.) What happened to the content of F12's Deployment Guide?
2.) What's the difference between the SELinux guides?
3.) What's the difference between "Managing Confined Serivces" and
"Security?"
4.) Why are there tips for SELinux in "Managing Confined Services?"
5.) Where is the answer to my question?
6.) My question isn't answered here, so now what?
These are not problems with the guides themselves, but with the
Publican-created website that offers no help in finding help. Sure,
there's a search box, and sure I could answer those questions by reading
the documents and comparing, but I think we can do better. I only
resort to a search if I can't guess my way through a site.
Here's what I'd like to see as a user:
1.) I need help.
2.) I go to fedoraproject.org
3.) I click "Get Help," and somehow decide that "Documentation" is right
for me (it should be advertised better).
4.) I'm greeted by a visual/written organizer that helps me see which
guide I want.
5.) My web browser automatically detects which version of Fedora I'm
using, or else I am asked, and provided a list with the
currently-supported versions displayed and an "other versions" button to
access documentation for not-currently-supported versions.
6.) If I can't find the answer to my problems, I get directed back to
the "Get Help" page, or to upstream documentation.
All the while, the familiar fp.o website look and feel has stayed the
same, as seen in the top and left portions of this page:
http://fedoraproject.org/en/get-help
Quaid:
>1. Write/edit
This is a task separate from reading documents, so we can use a
different application. My preference is for an extension to an existing
text editor, that:
-incorporates well-known text-editing features,
-incorporates DocBook XML help,
-incorporates fast/easy ways to get and commit what you've been working on.
Emacs could accomplish these things, but it's not a great solution.
Contributors would have to learn how to use emacs first, and then learn
how to use the Docs extensions to emacs. Emacs is not easy to use, or a
friendly application. It terrifies me.
This could be written as an extension or plugin for GEdit, but again I
don't feel this is a great solution. Users might feel like they need to
learn two things (like with an emacs extension), and they might rightly
feel like they aren't being provided with a fully-customized,
Docs-tailored experience. Of course, they're right about that - other
things go on in GEdit, too.
My preference would be for an editor incorporating the KWrite KPart. I
don't know the details of this, but it might have dependencies in KDE,
which makes this choice much less attractive for a GNOME distribution.
They may or may not be that troublesome. Here are some benefits to this
approach:
-it will result in a fully-customized application; users might not even
notice that it's built primarily with KPart's
-you can incorporate many different KPart's: like the web-browsing one,
which would allow you to use some web-based interface, or view DocBook
XML help files online; or the PDF-viewing one, which would allow you to
preview a PDF version of what you're working on
-users will feel like they need to learn only one thing, but we can also
take advantage of the fact that they'll instinctively be able to use the
KPart's
-the application basically already exists, and most of it would be
maintained for us by upstream KDE developers
It just seems so much more attractive to me to use a Publican front-end
called "Publican" than to have to start GEdit, turn on Publican mode,
and still have to use external applications to preview my work, or to
get help.
Quaid:
>2. Publish
A much smaller number of people will be publishing, compared to the
number writing and editing. The publishing tasks could be incorporated
into a text-editing GUI, but since you're just moving things around on
the internet, it makes more sense to use a web-based application for this.
I hadn't intended to advocate against a CMS, but it looks like I will.
"The Unix(TM) Way" is to build tools that do one thing well, and combine
them into things that accomplish Useful Work. This is what would be
happening with a KPart-based GUI editor. Keeping with that same line of
thought, it doesn't make sense to use a single (web-based) tool to do
three different tasks: reading, writing, and publishing. These are
distinctly different tasks, so we should use distinctly different tools.
Moreover, this separation will help us to tailor each tool to its
specific task.
Most people who use the official documentation will not be writing them,
and the official documentation should look professional/official. It's
not a wiki. The goal, as I understand it, is to make the barrier for
entry as low as possible, but it can't be seen as too low, or else it
discredits the project. I don't think we were at imminent risk of that,
but it's something to consider with a CMS.
The nice thing about this is that the Docs SIG already has a working
process, and already produces the best documentation of any Linux-based
operating system. It was the Four Fs that brought me to Fedora, but it
was the quality of the documentation that made me stay.
Christopher.
While I've been waiting to see how the Zikula deployment went with
Fedora Insight, we've finally seen a better update to
docs.fedoraproject.org by using the native Publican site building
tools. I've waited to push forward with a CMS solution for Fedora
Docs until we had a working solution to design against.
While Publican gives us a way to build a nicely organized tree of
content, it doesn't give other capabilities. I don't know of any
plans to include this sort of thing in Publican natively:
* Ability to trigger (re)builds from source repositories via a webUI.
* Workflow control, either by group (writers, editors, publishers), or
specific roles like that but per document (I can write this one, I
can edit yours, and I can push hers to publish after you edit it.)
* WYSIWYG editor for DocBook XML from source repository.
Basically, we still have very high barriers to move from "edit stuff
on the wiki" to "manage a full guide on DocBook XML." The main
purpose for a CMS is to get the ability to publish and tweak
docs.fedoraproject.org out of the hands of a very few, very busy
people, and in to the hands of just about anyone that this team wants
to authorize to do work there.
Talking in the meeting yesterday, I threw out some ideas around this
and agreed to bring those here. I'm still interested in helping drive
a CMS-like project for Docs.
So I'll throw out a proposal to get us started. This proposal exists
partially because of our commitment to using Publican to publish.
Another option is to use Publican only to generate documents, which
are then loaded and versioned in a CMS e.g. Zikula or Drupal. Working
under this other option would be more like the CMS experience others
have -- you either work in the native editor, or you upload documents
you created elsewhere.
== Docs CMS ==
=== Terms ===
* Publican is a command-line toolchain for building books as HTML,
PDF, Epub, Text, etc. and publishing them to a static website with
a navigation sidebar. It uses books written in DocBook XML that
exist as installable RPM packages.
* Beacon is a wysiwyg, webUI editor that has been extended to
support DocBook XML editing.
* Fedora Hosted (fh.o) is a hosting solution that is the source
repository for Fedora Docs. Books primarily use Subversion or git
as source control manager (SCM).
* WebUI is a generic term for the web user interface that we have to
write or configure to wrap around and perform certain functions
for this CMS. For example, it can present a button to a person
with publishing privileges, when pressed triggers of a Publican
build on the backend. This webUI could be custom code written in
Python and TurboGears, or it could be Drupal with a few custom
modules.
* A reader has the ability to read the website anonymously. No
credentials are required.
* A writer belongs to a 'doc-writers' group and also belong to the
group associated with each document, e.g. 'gitinstall-guide'.
Being in the 'doc-writers' group is a prerequisite that exposes
the Beacon editor function.
* An editor is the same as a writer, performing a different role in
the process.
* A publisher is a member of the 'doc-publishers' group, which gives
the permission to trigger special functions in the webUI - build a
doc, rebuild a doc, install a doc package, etc.
=== WebUI architecture ===
Functions:
0. Read
1. Write/edit
2. Publish
0. Read
a. Publican produces pages and navigation at docs.fp.org.
i. These pages are static and not wrapped by the webUI.
b. Readers use Publican's navigation to read guides.
1. Write/edit
a. Writer clicks "Check out document for editing" (this is NOT a
locking mechanism.)
i. Clicking check out triggers a 'git clone' of the document
repo.
ii. The cloned git repo is then branched locally to the webUI
server, for example 'git branch quaid-20100224-UUID' with a
short, sequential UUID such as 'AA00'.
iii. Beacon is then opened using the local file check out of the
XML.
iv. Beacon saves work only in the files in the cloned repo. An
added functionality could trigger 'git commit' on save, but
this might cause too many commits without a log message.
v. The writer's training includes knowing to commit on a regular
basis, in a granular fashion, when one or more edit+saves
makes a good bundle for a commit. Clicking on "Commit
changes" opens a log summary window, then a 'git commit -m
"$dump_from_log_summary_window" is done on the local repo.
vi. A writer's session should persist. When the writer returns
and still has local changes committed but not pushed to the
master git repo, the writer is offered those files to
continue work on, or to checkout a different document.
vii. When the writer is done with the writing session, the
writer clicks a "Check in document to main repository".
This triggers a 'git push' to the master repository.
2. Publish
a. Publisher selects a document and version from a
dropdown/checklist menu.
i. This list is generated from installed packages on docs.fp.o,
information extracted using 'rpm' commands.
b. Publisher clicks "Rebuild and publish document."
i. A koji scratchbuild is triggered, which grabs the latest
source from the upstream repository and builds a package.
ii. When the build is done, the package is installed from koji
using yum.
c. Publisher adds a new document to the publish list.
i. Document must exist as package in koji already.
ii. Publisher uses a Moksha widget to identify the meta-package
OR a specific package name and version are supplied
manually.
iii. Package is installed on docs.fedoraproject.org.
iv. Cached list of installed packages is refreshed to update
document and version dropdown/checklist menus.
<eof>
- Karsten
--
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
uri: http://TheOpenSourceWay.org/wiki
gpg: AD0E0C41
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
REMINDER: There will be a Fedora Docs Meeting today at 2300 UTC. The
agenda can be found at:
http://fedoraproject.org/wiki/Docs_Project_meetings#Agenda_for_Next_Meeting
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMIfyIAAoJEDbiLlqcYamxVZ0P/2pSN2MjnHJ1WC8nNPJbBAGr
39Dz2w+jymYf53W5oxGelrnzSoCEwtA8Sb1iaonhxbPSCJwXywsPj+SHP3kXyrmZ
pdn1Eb8+pCVKRY2OQKRbyG8zk4BU/EA2We8wAOBt/y6wVNK/hqNZ0d4tcItIJ+Rn
yoVVp1LE+OAjBzrBmUD+jRKExra0keRKv97zVhiruY/U3kIplYBrMNUE+Omt1VEd
U7Y3yq9inHIKvjJ09VzSPHilh092L1CtW4vO4ZToiZ62aPfptGDYaAzwIicogiM8
vHlZq8LAle6LaX8T6AR2fDEQdVKiCYJuuReg8zIqRzPbR2dNJtrynPi6OODeZHQA
RxyJrOcpn6g7uUY5CKEg6jh41mggTIFFLVGiKOYZ9DgleVNt1SgvV5fvVkGmKq7a
1bdgDKC3QDvOxasoRQ9YDQXfSMdt4N1YHF9bjD+c6ZM3zrKUyedm0L41UQnCc8ty
3zNZ9AfwklZi90IXEPl1DsIe1DG18f0ZFifxqmt7mwSoZvIChl8a2kJ0LptZwirG
pTMsgzVS2uqTD9dMFFv0BLP1yT2BQL6fS7epKz+Bg19ogxLYXeU4Fz138FfcSg8V
MfMUxhyorOW946b/3yQsHJttZP/OMOSqJWAxQVSa80TPmQup3VN0b6Eh4phg2pJ2
jdQ/Eo/4q7PJm624Am8s
=qhu3
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm working on the Jargon Buster. The old XML contains tags that are no
longer used. It appears to create a glossary. So what replaces the
tags that are there?
<glossentry id="gl-jb-a11y">
<glossterm>a11y</glossterm>
<glossdef>
<para>
An abbreviation for "accessibility," frequently used in
programming to avoid unnecessary typing and misspelling.
Accessibility is the provision of services for impaired
users, such as text-to-speech translation for the visually
impaired. The <literal>11</literal> derives from the eleven
letters between the beginning <literal>a</literal> and the
ending <literal>y</literal>.
</para>
</glossdef>
</glossentry>
Thanks,
Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMHOkVAAoJEDbiLlqcYamxNR8QAIFuEcMh1hGVaUCOQenD1Fql
4mAOFUOuzmyok7W6iClUu4IPs/vBFULs28Ioin0Whm9qwXMWBrm2cjMhC8ftup/g
NlWFqX6TvolJYrfTWLcnqS86Aao+jaeXzAFWPdt+jVtkRL0MNExNnZ33NNGKnIY1
49lK4gIsKlouX1Fh9wcyIwQc7QbQMCv9uAmBm/W4+tltdYIN8YoPGCn9G0NzypR6
W3l4he2nBu8nEp0TVCU7j/RFKaYhK0fzvQUDGTz4hqsKDSFrgE6I/141wE0QeOfA
N8+4j5rWNQ172v8tXkx/+hIzKyopApeXcOj0K7O0vZNQYHhlNDx0G41sC1sgRuD9
4Ig9HAKXfzFzjUHMBxOO4VaI0buBG6YG6CtixEC3etwB6nLmJ/5p1Wb0BreRkopq
Zr3FJvwYLuGvg2Bz45v1DBh6JL5eR5anpoqsQYM0/Cp6BYdH+AroiYwjG7BNNlcc
GAatMwBqm7hfdtpuEhXiCTL3vXysDQdfkr59Y/ss/HR/PlliiQLYHoHR/u1kuNt5
w7rsthb6/LJO6Ew27RlVuoue1fKHw58GB/doH3fjpn/ofv3829Amie/IVZuFdu8r
W+4gCg2jZ14MaroSVYnFBRXL9mHLEFGtGbdC9/UaYXp1OAhDCXQmkafZ99ePSfbE
1VaOFaf273KXqqbR1x3S
=kfip
-----END PGP SIGNATURE-----
Hi everyone,
I'm Satinderjit Singh Grewal from Punjab. My IRC and fedora nick is
satindergrewal.
==> What other projects or writing have you worked on in the past?
I've been working as a Linux Administrator since 2007. Earlier I was working
as a freelance web developer, which is now turned as my profession. Recently
I completed my work on translating Joomla CMS Language Pack to Punjabi,
which includes several other third party Joomla Extensions such as
JomCommet, MyBlog, JomSocial, Alpha Registration and Joom Donation.
==> What level and type of computer skills do you have?
Advanced computer skills:
1. Linux/Windows Network Administration,
2. Virtualization
Intermediate skills:
1. Asterisk VoIP
Basic skills:
1. PHP, MySQL
==> What other skills do you have that might be applicable? User interface
design, other so-called soft skills (people skills), programming, etc.
1. Graphics/UI Designing with Photoshop and Flash,
2. Expertise in CMS/Forums: Joomla, Wordpress, Moodle, phpBB, vBulletin
3. Languages Read/Write/Listen: Punjabi, Hindi, English (High)
4. Creating Video Guides - http://youtube.com/openitcrew
5. Programming: HTML, Stylesheet, Linux Shell Scripting
==> What makes you an excellent match for the project?
I have been into Web Development since 2004-2005, and in Linux since 2007. I
was always willing to contribute from my side to Open Source Projects, but
due to lack in programming languages I couldn't. Having interest and
experience in various areas where I can put my efforts and contribute
something. Such as Graphics/UI Designing, Language, Documentation, Guides
and Tutorials.
==> GPG KEYID and fingerprint
[satinder@localhost ~]$ gpg --fingerprint AFDF2526
pub 2048R/E82B2CAF 2010-06-20 [expires: 2011-06-20]
Key fingerprint = 0C59 932E 09CE D3A6 E1F3 BCE3 BB77 5054 E82B 2CAF
uid Satinderjit Singh (Fedora Open Source Projects) <
grewal.satinder(a)gmail.com>
sub 2048R/AFDF2526 2010-06-20 [expires: 2011-06-20]