From Fedora Project Wiki
m (1 revision(s))
m (Deprecation category and notice. This page will not be deleted.)
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Deprecated}}
= Plans =
= Plans =


Here are some detailed plans on what we can do in the localization landscape. Maybe "ideas" is a better word. Mostly ideas specific to tools, gathered in mailing lists and at FOSS.in when a bunch of translators and developers gathered around.
Here are some detailed plans on what we can do in the localization landscape. Maybe "ideas" is a better word. Mostly ideas specific to tools, gathered in mailing lists and at FOSS.in when a bunch of translators and developers gathered around.


{{ Template:message/notice | These aren't official plans of the FLP, just a bunch of useful notes and food for thought.
{{Admon/tip | These aren't official plans of the FLP, just a bunch of useful notes and food for thought.}}
}}
 
[[TableOfContents()] 


== Correct what's not working (fix) ==
== Correct what's not working (fix) ==
Line 12: Line 10:
=== Priority 1 ===
=== Priority 1 ===


* Put Transifex into production at translate.fpo (100% complete)
* OK - Put Transifex into production at translate.fpo (100% complete)
* (./) Add missing modules & branches, do some final checks
* OK - Add missing modules & branches, do some final checks
* Announce (Fedora and lwn/foo)
* OK - Announce (Fedora and lwn/foo)
* (./) Make sure statistics and every piece of the puzzle works
* OK - Make sure statistics and every piece of the puzzle works
* OK - Mass-email elvis users to create Fedora accounts (/L10N/Join page is ready)
* OK - IRC for help in registration process (sign CLA etc)


* Migrate users from elvis
Others:
* (./) Mass-email elvis users to create Fedora accounts (/L10N/Join page is ready)
 
* (./) IRC for help in registration process (sign CLA etc)
* CANTFIX (no resources) - Migrate users from elvis


=== Priority 2 ===
=== Priority 2 ===


* Add email notifications
* OK in v05 - Add email notifications
* For every commit, new module (or edit), notify related people
* OK in v05 - For every commit, new module (or edit), notify related people
* Expose public parts as RSS too
* OK in v05 - Expose public parts as RSS too
* OK - Enable all projects in Transifex
* OK - Contact hosted.fpo-hosted developers to add their project too (eg. opyum)
* OK - Communicate with rest of elvis devs and urge them to move to Fedora infra
* OK - Enable Tx on both app servers
* OK in v05 - Add possibility to set flag with Tx (hold/release a package)


* Enable all projects in Transifex
* Contact hosted.fpo-hosted developers to add their project too (eg. opyum)
* (./) Communicate with rest of elvis devs and urge them to move to Fedora infra


* Enable Tx on both app servers
== Increase efficiency (enhance) ==
 
* Add possibility to set flag with Tx (hold/release a package)


=== Priority 1 ===


== Increase efficiency (enhance) ==
* OK in v05 - Code high-level views for maintenance
* OK in v05 - Big table with registered modules, releases, branches
* OK in v05 - DL: Keep in sync with upstream, convince them to do releases
* OK in v05 - Move DL SQLite to mysql, have one app server to update the DB and the rest just their caches
* OK in v05 - Configure DL to get notifications for each commit from each VCS (probably via Tx) and update LIVE the module's statistics, instead of running the cron job every a few hours.
* OK in v05 - Separate Tx commit mechanism from web app to a separate process/service. (big project) Benefits: Increased security (apache no access to the SSH keys), enable an upstream project to actually do the commit/push, Tx only requests the commits (good for GNOME, KDE, etc)
* OK in v05 - Increase verbosity in tools: Add more links and common info in both DL+Tx (eg. mention on the top of each page how to checkout and where from to checkin respectively, links to bugzilla and maintainers, etc).


=== Priority 1 ===
Others:


* Code high-level views for maintenance
* Big table with registered modules, releases, branches
* Same table for Tx but also test write access for each module/branch
* Same table for Tx but also test write access for each module/branch
* SSH key overview/administration (admins)
* SSH key overview/administration (admins)
 
* CANTFIX (no resources) - DL+Tx: Make sure all branches/modules are there, all the time. This applies for all registered super-projects (Fedora, RHEL, CentOS, OLPC)
* Need maintenance resources for DL and Tx
* DL: Keep in sync with upstream, convince them to do releases
* DL+Tx: Make sure all branches/modules are there, all the time. This applies for all registered super-projects (Fedora, RHEL, CentOS, OLPC)
 
* Move DL SQLite to mysql, have one app server to update the DB and the rest just their caches
 
* Configure DL to get notifications for each commit from each VCS (probably via Tx) and update LIVE the module's statistics, instead of running the cron job every a few hours.
 
* Separate Tx commit mechanism from web app to a separate process/service. (big project)
* Benefits: Increased security (apache no access to the SSH keys), enable an upstream project to actually do the commit/push, Tx only requests the commits (good for GNOME, KDE, etc)
 
* Increase verbosity in tools: Add more links and common info in both DL+Tx (eg. mention on the top of each page how to checkout and where from to checkin respectively, links to bugzilla and maintainers, etc).


=== Priority 2 ===
=== Priority 2 ===


* Give more control to developers directly
* OK in v05 - Give more control to developers directly
* Add web-based interface for developers to register their projects
* OK in v05 - Add web-based interface for developers to register their projects
* Give them the ability to add a new branch to their module
* OK in v05 - Give them the ability to add a new branch to their module
* Give Transifex access directly through the FAS (reduced overhead on Fedora Infra)
* OK - Give Transifex access directly through the FAS (reduced overhead on Fedora Infra)
* OK in v05 - Build RPM for DL and push DL+Tx RPMs in Fedora Universe
* OK in v05 - Build a common model/configuration with DL (maintenance cost down).
* OK in v05 - Create similar models to DL in Tx. Experiment in running DL scripts to populate them. Goal: Not having to maintain two separate Views, configuration files, checked-out caches.


* Expose repos: Give developers the ability to pull translations instead of having Tx push them
Others:


* Build RPM for DL and push DL+Tx RPMs in Fedora Universe
* WONTFIX (we have a better solution with intermediate repos) - Expose repos: Give developers the ability to pull translations instead of having Tx push them
 
* Build a common model/configuration with DL (maintenance cost down).
* Create similar models to DL in Tx. Experiment in running DL scripts to populate them. Goal: Not having to maintain two separate Views, configuration files, checked-out caches.




Line 77: Line 70:
=== Priority 1 ===
=== Priority 1 ===


* Implement VCS-agnostic CLI client to work independantly of the web interface (big project)
* OK (could need some more love) - Get in touch with RH Docs to see if they could work closer with the community and leverage its throughput
* Eg. <code>tx checkout --all</code> and <code>tx submit <proj> <branch> <file></code>
* OK in v05 - Test OpenID
* Somewhat related with Pootle integration
* OK in v05 - Make Tx *completely* portable to any independent project that wants its resources localized
* Could get integrated with kbabel, gtranslator, etc.


* Pootle: Make it work with Transifex
Others:
* See what is/isn't needed and customize accordingly
* Install a test instance, even without Tx for specspo
 
* RH Docs
* Get in touch with folks to see if they could work closer with the community and leverage its throughput
* Why not have the docs in some "unofficially supported" languages too?


* Planned: Implement VCS-agnostic CLI client to work independantly of the web interface (big project). Eg. <code>tx checkout --all</code> and <code>tx submit <proj> <branch> <file></code>
* Maybe someday: Could get integrated with kbabel, gtranslator, etc.
* Planned: Pootle: Make it work with Transifex. See what is/isn't needed and customize accordingly.
* CANTFIX (no resources) - Install a test instance, even without Tx for specspo
* No feedback: Why not have the docs in some "unofficially supported" languages too?
* Discuss with Debian community their needs and requirements
* Discuss with Debian community their needs and requirements


* Test OpenID
=== Priority 2 ===


* Make Tx *completely* portable to any independent project that wants its resources localized
* OK in v05 - Add ability to "hold" and "release" a project/branch, like in elvis
* OK - Start thinking big
* OK in v05 - Have language-specific and project-specific sub-domains, specific content for each
* Planned: Fine-grain permissions in Tx: Language maintainers, approvals by proj/lang/branch, etc. Who owns what, who controls what.


=== Priority 2 ===
== Community ==
 
* Fine-grain permissions in Tx: Language maintainers, approvals by proj/lang/branch, etc. Who owns what, who controls what.
* Add ability to "hold" and "release" a project/branch, like in elvis


* Start thinking big
* OK - Send emails to -announce before every release
* Have language-specific and project-specific sub-domains, specific content for each


== Community ==
Others:


* Continue building groups, mailing lists, the community
* Continue building groups, mailing lists, the community
* Work better together with Ambassadors -- look at Ubuntu for "loco teams"
* Work better together with Ambassadors -- look at Ubuntu for "loco teams"
* Send emails to -announce before every release
* Give credits in all Fedora-is-upstream applications/docs
* Give credits in all Fedora-is-upstream applications/docs
* Bi-weekly meetings
* Bi-weekly meetings
Line 119: Line 108:
* Docs in general! LTSP? Manpages?
* Docs in general! LTSP? Manpages?


----
[[Category:Localization]][[Category:Deprecated]]
[[Category:Localization]]

Latest revision as of 18:55, 25 June 2009

Important.png
This page is outdated and is only retained for historical reference


Plans

Here are some detailed plans on what we can do in the localization landscape. Maybe "ideas" is a better word. Mostly ideas specific to tools, gathered in mailing lists and at FOSS.in when a bunch of translators and developers gathered around.

Idea.png
These aren't official plans of the FLP, just a bunch of useful notes and food for thought.

Correct what's not working (fix)

Priority 1

  • OK - Put Transifex into production at translate.fpo (100% complete)
  • OK - Add missing modules & branches, do some final checks
  • OK - Announce (Fedora and lwn/foo)
  • OK - Make sure statistics and every piece of the puzzle works
  • OK - Mass-email elvis users to create Fedora accounts (/L10N/Join page is ready)
  • OK - IRC for help in registration process (sign CLA etc)

Others:

  • CANTFIX (no resources) - Migrate users from elvis

Priority 2

  • OK in v05 - Add email notifications
  • OK in v05 - For every commit, new module (or edit), notify related people
  • OK in v05 - Expose public parts as RSS too
  • OK - Enable all projects in Transifex
  • OK - Contact hosted.fpo-hosted developers to add their project too (eg. opyum)
  • OK - Communicate with rest of elvis devs and urge them to move to Fedora infra
  • OK - Enable Tx on both app servers
  • OK in v05 - Add possibility to set flag with Tx (hold/release a package)


Increase efficiency (enhance)

Priority 1

  • OK in v05 - Code high-level views for maintenance
  • OK in v05 - Big table with registered modules, releases, branches
  • OK in v05 - DL: Keep in sync with upstream, convince them to do releases
  • OK in v05 - Move DL SQLite to mysql, have one app server to update the DB and the rest just their caches
  • OK in v05 - Configure DL to get notifications for each commit from each VCS (probably via Tx) and update LIVE the module's statistics, instead of running the cron job every a few hours.
  • OK in v05 - Separate Tx commit mechanism from web app to a separate process/service. (big project) Benefits: Increased security (apache no access to the SSH keys), enable an upstream project to actually do the commit/push, Tx only requests the commits (good for GNOME, KDE, etc)
  • OK in v05 - Increase verbosity in tools: Add more links and common info in both DL+Tx (eg. mention on the top of each page how to checkout and where from to checkin respectively, links to bugzilla and maintainers, etc).

Others:

  • Same table for Tx but also test write access for each module/branch
  • SSH key overview/administration (admins)
  • CANTFIX (no resources) - DL+Tx: Make sure all branches/modules are there, all the time. This applies for all registered super-projects (Fedora, RHEL, CentOS, OLPC)

Priority 2

  • OK in v05 - Give more control to developers directly
  • OK in v05 - Add web-based interface for developers to register their projects
  • OK in v05 - Give them the ability to add a new branch to their module
  • OK - Give Transifex access directly through the FAS (reduced overhead on Fedora Infra)
  • OK in v05 - Build RPM for DL and push DL+Tx RPMs in Fedora Universe
  • OK in v05 - Build a common model/configuration with DL (maintenance cost down).
  • OK in v05 - Create similar models to DL in Tx. Experiment in running DL scripts to populate them. Goal: Not having to maintain two separate Views, configuration files, checked-out caches.

Others:

  • WONTFIX (we have a better solution with intermediate repos) - Expose repos: Give developers the ability to pull translations instead of having Tx push them


Add functionality (extend)

Priority 1

  • OK (could need some more love) - Get in touch with RH Docs to see if they could work closer with the community and leverage its throughput
  • OK in v05 - Test OpenID
  • OK in v05 - Make Tx *completely* portable to any independent project that wants its resources localized

Others:

  • Planned: Implement VCS-agnostic CLI client to work independantly of the web interface (big project). Eg. tx checkout --all and tx submit <proj> <branch> <file>
  • Maybe someday: Could get integrated with kbabel, gtranslator, etc.
  • Planned: Pootle: Make it work with Transifex. See what is/isn't needed and customize accordingly.
  • CANTFIX (no resources) - Install a test instance, even without Tx for specspo
  • No feedback: Why not have the docs in some "unofficially supported" languages too?
  • Discuss with Debian community their needs and requirements

Priority 2

  • OK in v05 - Add ability to "hold" and "release" a project/branch, like in elvis
  • OK - Start thinking big
  • OK in v05 - Have language-specific and project-specific sub-domains, specific content for each
  • Planned: Fine-grain permissions in Tx: Language maintainers, approvals by proj/lang/branch, etc. Who owns what, who controls what.

Community

  • OK - Send emails to -announce before every release

Others:

  • Continue building groups, mailing lists, the community
  • Work better together with Ambassadors -- look at Ubuntu for "loco teams"
  • Give credits in all Fedora-is-upstream applications/docs
  • Bi-weekly meetings
  • Split specspo in chunks of reduced priority.
  • Also, make it work with rpm (spot)

Other ideas worth considering

  • JBOSS Docs, similar to RH Docs
  • Docs in general! LTSP? Manpages?