I should have started this thread on Wednesday but my home schedule has been a bit topsy-turvy of late:
The Docs Project has been invited to participate in the next Fedora Project Board meeting. We should be prepared to talk about the successes we've had over the past two releases and what remains to be done. The way I see it, here are some starter issues. I'd appreciate plenty of input, but please keep in mind that the issues should be things the Board cares about (e.g. blockers in other subprojects that we haven't been able to resolve after repeated attempts, resource needs that might require Real Funds -- things we can't provide by ourselves).
Successes: 1. Best-in-the-world release notes, provided by the community. 2. Growing contributor base, including work on additional entry-level to intermediate-level guides. 3. Progress toward integrating with the Fedora package universe.
Future Predictions: 1. Possible click-thru on Wiki will allow easier contribution without all the GPG+SSH+CLA+EditGroup rigamarole 2. FUDCon presence will result in major updates to available docs, making it easier for new people to learn processes
Outstanding Issues: 1. Translation Project disconnect - what do we need here in concrete terms? App rewrites and process changes? Red Hat internal group(s) originally had ownership of this, yet we've seen no progress in the past months... or year(s). 2. Content from RH, licensed under our terms (OPL w/no options).
What else am I missing -- especially in the third area?
Le vendredi 05 janvier 2007 à 11:15 -0500, Paul W. Frields a écrit :
I should have started this thread on Wednesday but my home schedule has been a bit topsy-turvy of late:
The Docs Project has been invited to participate in the next Fedora Project Board meeting. We should be prepared to talk about the successes we've had over the past two releases and what remains to be done. The way I see it, here are some starter issues. I'd appreciate plenty of input, but please keep in mind that the issues should be things the Board cares about (e.g. blockers in other subprojects that we haven't been able to resolve after repeated attempts, resource needs that might require Real Funds -- things we can't provide by ourselves).
Successes:
- Best-in-the-world release notes, provided by the community.
- Growing contributor base, including work on additional entry-level
to intermediate-level guides. 3. Progress toward integrating with the Fedora package universe.
Future Predictions:
- Possible click-thru on Wiki will allow easier contribution without
all the GPG+SSH+CLA+EditGroup rigamarole 2. FUDCon presence will result in major updates to available docs, making it easier for new people to learn processes
Outstanding Issues:
- Translation Project disconnect - what do we need here in concrete
terms? App rewrites and process changes? Red Hat internal group(s) originally had ownership of this, yet we've seen no progress in the past months... or year(s).
There are simple things that may be sufficient to help improving translation. 1. make it easy to subscribe to the project in itself. It _is_ really a pain to open that much of account to translate a string. That shouldn't. 2. do not allow people to commit as they want. New contributors (as well as every pieces of translation) must be read over by someone more experienced in the projet. A bit like extras packages are reviewed before being accepted. This will avoid many mistakes in the distribution. 3. better communication between developers and translators. For example : a package sees its .pot file updated. That is the responsibility to check regurlary for this kind of update. But developers could say on the translation list : i'm going to rebuild the updated software into a RPM package by (any date) and all translation done before that date will be included.
That's all I'd like :)
From my point of view, I don't think it could be that indispensable to
have the same webapp than Launchpad offers for translation, that is, translation directly from the web browser. I personally don't trust any web browser, their stability depending on the websites you are on.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Posting this to fedora-trans too, to get some translators input
Thomas Canniot schreef:
Le vendredi 05 janvier 2007 à 11:15 -0500, Paul W. Frields a écrit :
I should have started this thread on Wednesday but my home schedule has been a bit topsy-turvy of late:
The Docs Project has been invited to participate in the next Fedora Project Board meeting. We should be prepared to talk about the successes we've had over the past two releases and what remains to be done. The way I see it, here are some starter issues. I'd appreciate plenty of input, but please keep in mind that the issues should be things the Board cares about (e.g. blockers in other subprojects that we haven't been able to resolve after repeated attempts, resource needs that might require Real Funds -- things we can't provide by ourselves).
Successes:
- Best-in-the-world release notes, provided by the community.
- Growing contributor base, including work on additional entry-level
to intermediate-level guides. 3. Progress toward integrating with the Fedora package universe.
Future Predictions:
- Possible click-thru on Wiki will allow easier contribution without
all the GPG+SSH+CLA+EditGroup rigamarole 2. FUDCon presence will result in major updates to available docs, making it easier for new people to learn processes
Outstanding Issues:
- Translation Project disconnect - what do we need here in concrete
terms? App rewrites and process changes? Red Hat internal group(s) originally had ownership of this, yet we've seen no progress in the past months... or year(s).
There are simple things that may be sufficient to help improving translation.
- make it easy to subscribe to the project in itself. It _is_ really a
pain to open that much of account to translate a string. That shouldn't. 2. do not allow people to commit as they want. New contributors (as well as every pieces of translation) must be read over by someone more experienced in the projet. A bit like extras packages are reviewed before being accepted. This will avoid many mistakes in the distribution. 3. better communication between developers and translators. For example : a package sees its .pot file updated. That is the responsibility to check regurlary for this kind of update. But developers could say on the translation list : i'm going to rebuild the updated software into a RPM package by (any date) and all translation done before that date will be included.
That's all I'd like :)
Maybe also checkout the thread[1] on fedora-trans-list from a few weeks ago on this very subject
From my point of view, I don't think it could be that indispensable to
have the same webapp than Launchpad offers for translation, that is, translation directly from the web browser. I personally don't trust any web browser, their stability depending on the websites you are on.
As far as I know Launchpad will never be an option, as it's closed source. Lately I've been wanting to look into Pootle[1], which offers some similar functionality and is written in Python.
Maybe all this stuff on L10N should have it's own separate meeting with the Board, as it's such a big change/challenge to get this right. I can think of some people who would like to join that meeting then, and we should get people from Docs and Infrastructure in that meeting as well (just my 2 ct).
Greetings, Bart
[1]: http://www.redhat.com/archives/fedora-trans-list/2006-November/msg00035.html [2]: http://translate.sourceforge.net/
Le dimanche 07 janvier 2007 à 09:37 +0100, Bart Couvreur a écrit :
Maybe also checkout the thread[1] on fedora-trans-list from a few weeks ago on this very subject
That I missed, thanks.
From my point of view, I don't think it could be that indispensable to
have the same webapp than Launchpad offers for translation, that is, translation directly from the web browser. I personally don't trust any web browser, their stability depending on the websites you are on.
As far as I know Launchpad will never be an option, as it's closed source. Lately I've been wanting to look into Pootle[1], which offers some similar functionality and is written in Python.
Maybe all this stuff on L10N should have it's own separate meeting with the Board, as it's such a big change/challenge to get this right. I can think of some people who would like to join that meeting then, and we should get people from Docs and Infrastructure in that meeting as well (just my 2 ct).
I can't wait to attend it :)
Greetings, Bart
On Sun, 2007-01-07 at 09:37 +0100, Bart Couvreur wrote:
Maybe all this stuff on L10N should have it's own separate meeting with the Board, as it's such a big change/challenge to get this right. I can think of some people who would like to join that meeting then, and we should get people from Docs and Infrastructure in that meeting as well (just my 2 ct).
Translation/L10N will get its own slot as well, fear not. This first meeting just happens to be Docs and since we're tied up in some of the Translation/L10N issues, we'll likely put our US $0.02 in.
On Fri, 2007-01-05 at 11:15 -0500, Paul W. Frields wrote:
I should have started this thread on Wednesday but my home schedule has been a bit topsy-turvy of late:
Heh, and my work schedule is the usual crazy, so I'm just getting to this.
Thanks for starting the thread, it helps me prepare for the meeting tomorrow.
Successes:
- Best-in-the-world release notes, provided by the community.
- Growing contributor base, including work on additional entry-level
to intermediate-level guides. 3. Progress toward integrating with the Fedora package universe.
4. Improvements in integrating/working with Fedora Infrastructure 5. Assisting QA/Testing Project with documentation/l10n
Future Predictions:
- Possible click-thru on Wiki will allow easier contribution without
all the GPG+SSH+CLA+EditGroup rigamarole 2. FUDCon presence will result in major updates to available docs, making it easier for new people to learn processes
3. Working across FLOSS projects and distros on improving common documentation we can all reuse; may happen as a series of injections upstream, or as a layer we share below upstream that does the injection.
Outstanding Issues:
- Translation Project disconnect - what do we need here in concrete
terms? App rewrites and process changes? Red Hat internal group(s) originally had ownership of this, yet we've seen no progress in the past months... or year(s).
1.1 Can we help move trans leadership into the community? Steering committee? Something where the distractions of one entity (Red Hat) don't disable the entire project leadership all at the same time.
- Content from RH, licensed under our terms (OPL w/no options).
2.1 In a timely fashion so it has meaning for F7
3. Getting more from the developer side; how to engage them? The Beats, while successful, are still teeth-pulling exercises before the release, messing up our work, trans, etc. Stuff like *docs* in CVS are unused; same for relnotes@fedoraproject.org. What can we do to improve the developers ability and likelihood of documenting?
4. Should FDP get involved in major cross-stream and upstream initiatives, such as man/info projects? What is the FPB's guidance/preference here?
I'll keep thinking on stuff. :)
- Karsten
For the record/archives, I put this item in the wrong place:
On Mon, 2007-01-08 at 09:42 -0800, Karsten Wade wrote:
Successes:
[...]
- Assisting QA/Testing Project with documentation/l10n
It is not _yet_ a success, it is instead:
Future Predictions:
... a future success just in the beginning stages.
- Karsten
docs@lists.stg.fedoraproject.org
-
Bart Couvreur -
Karsten Wade -
Paul W. Frields -
Thomas Canniot