Over the last few days it has been decided that we are going to move all of Fedora's translation efforts away from a self hosted solution and on to transifex.net.
The migration over to tx.net also means a huge jump to version 1.1 from 0.7, with that we no longer have support for tx to commit to the git repo[1]. This is going to require a redesign of our workflow to insure that we are publishing the most up to date.
The new system requires us to use a command-line tool, that is in the process of being packaged, and works much like git[1]. This means that we now have to pull in translations by hand, but tx.net can monitor the git repo (over HTTP) for changes that we make (you can also push via tx command).
Trans.fp.o will be turned off on Feb 18th, so we need to make sure that we have all of the current trans worked saved and then we need to work on moving to tx.net. We still have a little time to get that part of this figured out since we are not due to make POT files until March 15th, but we need to start looking at what this means for publishing to docs.fp.o and for packaging into the release.
It is important to remember that the pains that we may be dealing with are not because of the migration to tx.net but because of the upgrade to 1.1, which would have happend regardless. If anyone has any questions or concerns please don't hesitate to ask!
I am going to add this to the agenda for tonights meeting as well.
[1]: http://help.transifex.net/user-guide/one-dot-zero.html [2]: http://help.transifex.net/user-guide/client/client-0.4.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 02/16/2011 09:43 AM, Zach Oglesby wrote:
Over the last few days it has been decided that we are going to move all of Fedora's translation efforts away from a self hosted solution and on to transifex.net.
The migration over to tx.net also means a huge jump to version 1.1 from 0.7, with that we no longer have support for tx to commit to the git repo[1]. This is going to require a redesign of our workflow to insure that we are publishing the most up to date.
The new system requires us to use a command-line tool, that is in the process of being packaged, and works much like git[1]. This means that we now have to pull in translations by hand, but tx.net can monitor the git repo (over HTTP) for changes that we make (you can also push via tx command).
Trans.fp.o will be turned off on Feb 18th, so we need to make sure that we have all of the current trans worked saved and then we need to work on moving to tx.net. We still have a little time to get that part of this figured out since we are not due to make POT files until March 15th, but we need to start looking at what this means for publishing to docs.fp.o and for packaging into the release.
It is important to remember that the pains that we may be dealing with are not because of the migration to tx.net but because of the upgrade to 1.1, which would have happend regardless. If anyone has any questions or concerns please don't hesitate to ask!
I am going to add this to the agenda for tonights meeting as well.
This sounds like a great opportunity for the translators to better own their translations. I know at one point we were looking at translators being responsible for publishing and packaging their translations when they felt their translations were ready. This would solve the problem of us Docs folks arbitrarily publishing translations.
It is unfortunate that tx.net can't interface with our git repositories, though. I'd hate to loose data in a system we don't have control over.
- --Eric
On Wed, Feb 16, 2011 at 10:31:21AM -0500, Eric "Sparks" Christensen wrote:
On 02/16/2011 09:43 AM, Zach Oglesby wrote:
Over the last few days it has been decided that we are going to move all of Fedora's translation efforts away from a self hosted solution and on to transifex.net.
The migration over to tx.net also means a huge jump to version 1.1 from 0.7, with that we no longer have support for tx to commit to the git repo[1]. This is going to require a redesign of our workflow to insure that we are publishing the most up to date.
The new system requires us to use a command-line tool, that is in the process of being packaged, and works much like git[1]. This means that we now have to pull in translations by hand, but tx.net can monitor the git repo (over HTTP) for changes that we make (you can also push via tx command).
Trans.fp.o will be turned off on Feb 18th, so we need to make sure that we have all of the current trans worked saved and then we need to work on moving to tx.net. We still have a little time to get that part of this figured out since we are not due to make POT files until March 15th, but we need to start looking at what this means for publishing to docs.fp.o and for packaging into the release.
It is important to remember that the pains that we may be dealing with are not because of the migration to tx.net but because of the upgrade to 1.1, which would have happend regardless. If anyone has any questions or concerns please don't hesitate to ask!
I am going to add this to the agenda for tonights meeting as well.
This sounds like a great opportunity for the translators to better own their translations. I know at one point we were looking at translators being responsible for publishing and packaging their translations when they felt their translations were ready. This would solve the problem of us Docs folks arbitrarily publishing translations.
It is unfortunate that tx.net can't interface with our git repositories, though. I'd hate to loose data in a system we don't have control over.
IF you're worried about data loss, you could ask the Tx.n administrators directly about the integrity/backup mechanisms they have in place against data loss. AIUI TX.n can provide full translation history via git, which means our ability to get data out of the system should be unimpeded. (Also, the code used to run Tx.n is 100% FOSS so we can do crazy manipulations or even make RFE's if needed.)
On Wed, Feb 16, 2011 at 11:34 PM, Paul W. Frields stickster@gmail.com wrote:
On Wed, Feb 16, 2011 at 10:31:21AM -0500, Eric "Sparks" Christensen wrote:
On 02/16/2011 09:43 AM, Zach Oglesby wrote:
Over the last few days it has been decided that we are going to move all of Fedora's translation efforts away from a self hosted solution and on to transifex.net.
The migration over to tx.net also means a huge jump to version 1.1 from 0.7, with that we no longer have support for tx to commit to the git repo[1]. This is going to require a redesign of our workflow to insure that we are publishing the most up to date.
The new system requires us to use a command-line tool, that is in the process of being packaged, and works much like git[1]. This means that we now have to pull in translations by hand, but tx.net can monitor the git repo (over HTTP) for changes that we make (you can also push via tx command).
Trans.fp.o will be turned off on Feb 18th, so we need to make sure that we have all of the current trans worked saved and then we need to work on moving to tx.net. We still have a little time to get that part of this figured out since we are not due to make POT files until March 15th, but we need to start looking at what this means for publishing to docs.fp.o and for packaging into the release.
It is important to remember that the pains that we may be dealing with are not because of the migration to tx.net but because of the upgrade to 1.1, which would have happend regardless. If anyone has any questions or concerns please don't hesitate to ask!
I am going to add this to the agenda for tonights meeting as well.
This sounds like a great opportunity for the translators to better own their translations. I know at one point we were looking at translators being responsible for publishing and packaging their translations when they felt their translations were ready. This would solve the problem of us Docs folks arbitrarily publishing translations.
It is unfortunate that tx.net can't interface with our git repositories, though. I'd hate to loose data in a system we don't have control over.
IF you're worried about data loss, you could ask the Tx.n administrators directly about the integrity/backup mechanisms they have in place against data loss.
We take regular backups, and we're in a process of increasing the frequency this happens. We'll explain more in the next days/week.
But the most important part is that one can use the client to export all files in regular intervals and commit them (even with a cronjob) to his own git tree.
AIUI TX.n can provide full translation history via git, which means our ability to get data out of the system should be unimpeded.
Correction: Transifex no longer providfes full translation history via git. We *might* provide a mechanism in the client in the future which could be converted to git history (JSON history data to git format-patch or something). But this will require a person with this itch to scratch. =)
(Also, the code used to run Tx.n is 100% FOSS so we can do crazy manipulations or even make RFE's if needed.)
True!
-d
On 02/17/2011 12:43 AM, Zach Oglesby wrote:
Over the last few days it has been decided that we are going to move all of Fedora's translation efforts away from a self hosted solution and on to transifex.net.
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
Does this seem acceptable?
I also want to take this opportunity to thank Dmitris for his extremely generous offer to host this massive project on behalf of Fedora. However, apart from the reasons I gave earlier, I also can't help but feel that this direction would be grossly unfair on Dmitris and his business. Indifex is, after all, a commercial venture, and server resources and bandwidth aren't free of charge -- especially on the scale contemplated for Fedora. Just before I came to work for Red Hat, I owned a small IT business myself, and know that every penny counts! :)
Cheers Rudi
On 2011-02-21 01:33:01 PM, Ruediger Landmann wrote:
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
First, let me say - I'm happy as long as the work gets done to make a Transifex instance usable and maintained for translators.
But one question - can you quantify exactly what we lose with switching to transifex.net? We discussed this in infrastructure, and the conclusion was that we only lose FAS auth (and we already spoke to spot about any CLA issues, and he said that it shouldn't be an issue). In return, we get an actually maintained Transifex instance that won't be (often) unusable and slow for translators.
What independence do we have with running our own instance? We don't have the people to maintain/upgrade it, and while we have the freedom to make code changes to our instance, we certainly don't have the manpower to actually make that happen. On the other hand, Dimitris and other Transifex developers have already been willing to put time into helping us with our instance, taking bug reports and patches from us, and making sure that we have good service on transifex.net.
The infrastructure team is already really happy not to have to put manpower into running bugzilla.redhat.com, and the way I see it, having a similar arrangement with transifex.net would be great for everybody.
Thanks, Ricky
On 02/21/2011 02:40 PM, Ricky Zhou wrote:
First, let me say - I'm happy as long as the work gets done to make a Transifex instance usable and maintained for translators.
Thanks Ricky :)
But one question - can you quantify exactly what we lose with switching to transifex.net?
As I see it, you answer your own question further down your post. We lose control of the instance. Whether or not the Fedora project ever exercises that control is a different matter.
Some people might see this as a purely theoretical distinction, but it's a distinction that exists at the very heart of Free software. With the exception of packages that I'm involved in maintaining, I have very rarely delved into the code or modified the code of the Free software that I use every day. However, by choosing Free software, I retain the ability to do these things if and when I choose to do so.
To me, this situation is analogous, and it's important to me that Fedora retains this freedom. Freedom means having the power to do something, not that you necessarily do that thing.
More pragmatically, needing to move translation files between transifex.net and our repos seems to me like an unfortunate hurdle to translations in Fedora. This is probably not a substantial disadvantage to relatively stable software packages where there is little change from version to version, but would be felt more in documentation where string changes are more frequent.
I am really very sorry that Red Hat has not stepped into the gap earlier to offer support for this part of the infrastructure and that the situation had to reach this crisis point. Nevertheless, the offer is out there now. If the L10N team accepts our help, we will of course need to put a plan in place to ensure that we provide some ongoing support (as we do with Bugzilla) -- at least until if and when somebody else in the community develops an interest in maintaining the instance.
Thanks again for the vote of confidence; it means a lot to me. I'm not deluded enough to imagine that this will be an easy task! :)
Cheers Rudi
On 2011-02-21 03:25:23 PM, Ruediger Landmann wrote:
As I see it, you answer your own question further down your post. We lose control of the instance. Whether or not the Fedora project ever exercises that control is a different matter.
Some people might see this as a purely theoretical distinction, but it's a distinction that exists at the very heart of Free software. With the exception of packages that I'm involved in maintaining, I have very rarely delved into the code or modified the code of the Free software that I use every day. However, by choosing Free software, I retain the ability to do these things if and when I choose to do so.
transifex.net runs on the same open source software that we run (albeit a much newer version). If we ever have the need to exercise control over the instance that transifex.net won't allow us, then we are always free to move back to running our own instance (the migration would work exactly like the one that's currently ongoing).
To me, this situation is analogous, and it's important to me that Fedora retains this freedom. Freedom means having the power to do something, not that you necessarily do that thing.
I don't think the situation is analogous to free vs. proprietary software. Again, Transifex is open source, and if we ever have the need, we can download/modify the source and go back to running our own version (although I don't really see this need arising, since they seem to have been great about helping us satisfy our needs in terms of features so far). Until such a need arises, we can save a ton of maintenance/sysadmin time by not running our own instance.
More pragmatically, needing to move translation files between transifex.net and our repos seems to me like an unfortunate hurdle to translations in Fedora. This is probably not a substantial disadvantage to relatively stable software packages where there is little change from version to version, but would be felt more in documentation where string changes are more frequent.
As we discussed in the other sub-thread, this change happens regardless of whether we run 1.1 in Fedora or on transifex.net. I consider this to be a huge improvement for the following reasons:
Sysadmin: - Don't have to manage shared storage when scaling transifex to run on multiple servers. In Fedora Infrastructure, this is one of the things we've been looking forward to the most with moving off of Transifex 0.x. - Don't have to worry about maintaining and securing private SSH keys with access to a bunch of upstream projects. Right now, we have to enter passphrases every time we restart a server with Transifex (and whenever we forget, the site is just broken for translators), and we also have to worry about securing a bunch of SSH keys to things that we'd rather just not have access to.
Developer: - I don't have to give Transifex or translators write access to my repo. Sure, access can be restricted with commit hooks or a file whitelist in Transifex, but those are a pain to maintain. - I get to control exactly when POT file changes are pushed and when PO file updates are pulled. - Developers can use whatever VCS they want without needing to worry about Transifex support. Back in the early days, Toshio had to spend time writing a Bazaar plugin in order to get Transifex support for his projects. Other developers use Monotone, Darcs, or maybe they don't use a VCS at all. The new model allows all of these people to use Transifex without issue.
Translator: - Common strings between projects can be shared. - Better failure handling. If the project's repo is down or unreachable for any reason, translations don't get denied - instead, they get saved, and the developer will still be able to pull and use them later (this kind of falls under sysadmin and developer too).
I am really very sorry that Red Hat has not stepped into the gap earlier to offer support for this part of the infrastructure and that the situation had to reach this crisis point. Nevertheless, the offer is out there now. If the L10N team accepts our help, we will of course need to put a plan in place to ensure that we provide some ongoing support (as we do with Bugzilla) -- at least until if and when somebody else in the community develops an interest in maintaining the instance.
I appreciate your work to find resources to maintain a Transifex instance, although the timing is pretty late, yes. I'm still not clear on exactly what freedoms we're losing out on, for the reasons I gave above.
Also note that even if we have some people dedicated to running Transifex for Fedora, the cost of maintaining it doesn't go away entirely. We still have to dedicate server resources, get woken up by alerts when it goes down, get the new sysadmins onto the team and trained on how we do things, and so on.
Thanks again for the vote of confidence; it means a lot to me. I'm not deluded enough to imagine that this will be an easy task! :)
Sorry to say this, but it's not quite a vote of confidence yet :-) I'm still trying to get more of a understanding on the reasons that some people don't want to move to transifex.net.
Thanks, Ricky
On 02/21/2011 04:10 PM, Ricky Zhou wrote:
On 2011-02-21 03:25:23 PM, Ruediger Landmann wrote:
As I see it, you answer your own question further down your post. We lose control of the instance. Whether or not the Fedora project ever exercises that control is a different matter.
Some people might see this as a purely theoretical distinction, but it's a distinction that exists at the very heart of Free software. With the exception of packages that I'm involved in maintaining, I have very rarely delved into the code or modified the code of the Free software that I use every day. However, by choosing Free software, I retain the ability to do these things if and when I choose to do so.
transifex.net runs on the same open source software that we run (albeit a much newer version). If we ever have the need to exercise control over the instance that transifex.net won't allow us, then we are always free to move back to running our own instance (the migration would work exactly like the one that's currently ongoing).
I'm sorry -- I didn't express myself clearly enough here, since both you and Jared have both understood something a little different from what I meant.
I know that Transifex is indeed Free software, and I certainly didn't mean to imply anything different. The parallel I'm drawing is this:
* Free software on my PC means that I can inspect or modify that software, whether or not I ever exercise that power.
* The Fedora Project's control of its own translation infrastructure means that we can inspect or modify that infrastructure, whether or not we ever exercise that power.
That's why I said the situation is analogous -- it's certainly not identical.
More pragmatically, needing to move translation files between transifex.net and our repos seems to me like an unfortunate hurdle to translations in Fedora. This is probably not a substantial disadvantage to relatively stable software packages where there is little change from version to version, but would be felt more in documentation where string changes are more frequent.
As we discussed in the other sub-thread, this change happens regardless of whether we run 1.1 in Fedora or on transifex.net.
I stand corrected on this point; but see below. Please take everything I say in the friendly and collegiate spirit in which it's intended. Line-by-line rebuttals inevitably come across as sounding quarrelsome, and that's not my intention at all. I've tried to keep that tone out of my responses, but if any has inadvertently slipped through, please forgive me :)
I consider this to be a huge improvement for the following reasons:
Sysadmin:
- Don't have to manage shared storage when scaling transifex to run on multiple servers. In Fedora Infrastructure, this is one of the things we've been looking forward to the most with moving off of Transifex 0.x.
- Don't have to worry about maintaining and securing private SSH keys with access to a bunch of upstream projects. Right now, we have to enter passphrases every time we restart a server with Transifex (and whenever we forget, the site is just broken for translators), and we also have to worry about securing a bunch of SSH keys to things that we'd rather just not have access to.
I have not been involved in maintaining the Transifex instance, so I'm not in a position to dispute these points.
Developer:
- I don't have to give Transifex or translators write access to my repo. Sure, access can be restricted with commit hooks or a file whitelist in Transifex, but those are a pain to maintain.
It's also a pain to have to remember to pull files manually and to have to maintain a configuration file. With the previous system, you set up the pseudo-user once and never had to think about it ever again. This made Transifex awesome :)
- I get to control exactly when POT file changes are pushed and when PO file updates are pulled.
Under what circumstances do you envisage maintainers might want to ship obsolete or less complete translations? Conversely, if your POT files aren't ready for translation, why are you pushing them into the repo?
And of course, you could do that with the previous Transifex as well.
- Developers can use whatever VCS they want without needing to worry about Transifex support. Back in the early days, Toshio had to spend time writing a Bazaar plugin in order to get Transifex support for his projects. Other developers use Monotone, Darcs, or maybe they don't use a VCS at all. The new model allows all of these people to use Transifex without issue.
All true; of course, once a plugin exists, everybody benefits. It's also a pity that it was either/or and that Transifex didn't have a fallback mechanism for the less widely used VCSes or projects without a VCS. What proportion of projects are we really talking about anyway?
Translator:
- Common strings between projects can be shared.
Does this happen? How much does it happen? In any case, I'm sceptical of the utility of matching strings taken from completely different contexts, but perhaps translators feel this isn't an issue?
- Better failure handling. If the project's repo is down or unreachable for any reason, translations don't get denied - instead, they get saved, and the developer will still be able to pull and use them later (this kind of falls under sysadmin and developer too).
I concur that this is a very real benefit. It's a shame that Transifex can't do both -- in other words, if it can't reach the project repo, that it stores the translation and alerts the maintainer and translator that there's been a problem but that the translation is safely stored for now.
I am really very sorry that Red Hat has not stepped into the gap earlier to offer support for this part of the infrastructure and that the situation had to reach this crisis point. Nevertheless, the offer is out there now. If the L10N team accepts our help, we will of course need to put a plan in place to ensure that we provide some ongoing support (as we do with Bugzilla) -- at least until if and when somebody else in the community develops an interest in maintaining the instance.
I appreciate your work to find resources to maintain a Transifex instance, although the timing is pretty late, yes. I'm still not clear on exactly what freedoms we're losing out on, for the reasons I gave above.
Also note that even if we have some people dedicated to running Transifex for Fedora, the cost of maintaining it doesn't go away entirely. We still have to dedicate server resources, get woken up by alerts when it goes down, get the new sysadmins onto the team and trained on how we do things, and so on.
Acknowledged.
Thanks again for the vote of confidence; it means a lot to me. I'm not deluded enough to imagine that this will be an easy task! :)
Sorry to say this, but it's not quite a vote of confidence yet :-) I'm still trying to get more of a understanding on the reasons that some people don't want to move to transifex.net.
The most fundamental reason is giving up control of a large and important piece of Fedora infrastructure to an outside entity. That's seriously unpalatable to a lot of people -- any understanding of why people don't want to move to transifex.net pretty much relies on acknowledging that, even if you don't feel the same way personally.
We obviously agree that having transifex.net host the instance results in less work for infra, but beyond that I'm not convinced that the move to transifex.net is better for developers or translators for any reason other than the reliability of maintenance (which is more-or-less the same point as it being less work for infra).
Thanks for the detailed reply and sorry that my response has taken so long -- I wanted to get it right. I'm taking particular notice of the advantages that you perceive in the move to transifex.net -- they provide very useful insight even where I do not necessarily agree.
Cheers Rudi
On 02/21/2011 06:25 AM, Ruediger Landmann wrote:
On 02/21/2011 02:40 PM, Ricky Zhou wrote:
First, let me say - I'm happy as long as the work gets done to make a Transifex instance usable and maintained for translators.
Thanks Ricky :)
But one question - can you quantify exactly what we lose with switching to transifex.net?
As I see it, you answer your own question further down your post. We lose control of the instance. Whether or not the Fedora project ever exercises that control is a different matter.
Some people might see this as a purely theoretical distinction, but it's a distinction that exists at the very heart of Free software. With the exception of packages that I'm involved in maintaining, I have very rarely delved into the code or modified the code of the Free software that I use every day. However, by choosing Free software, I retain the ability to do these things if and when I choose to do so.
To me, this situation is analogous, and it's important to me that Fedora retains this freedom. Freedom means having the power to do something, not that you necessarily do that thing.
+1
I completely agree with Rudi. An own infrastructure is always better because it *can* be adjusted for the needs of the project if needed.
Thanks,
Luc
Ruediger Landmann さんは書きました:
On 02/17/2011 12:43 AM, Zach Oglesby wrote:
Over the last few days it has been decided that we are going to move all of Fedora's translation efforts away from a self hosted solution and on to transifex.net.
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
Does this seem acceptable?
+1. Thank you very much for your proposal, I like to see this up and running. This is what we originally wanted. Fully functional transifex on fp.o allows all translators to continue working on same instance using same system without hassle for F15 software translation period which already started. Addition to this, translators can also be authenticated via FAS (cvsl10n group) as usual. It won't disturb other teams such as developers and web team by imposing the task for move as well.
I also want to take this opportunity to thank Dmitris for his extremely generous offer to host this massive project on behalf of Fedora. However, apart from the reasons I gave earlier, I also can't help but feel that this direction would be grossly unfair on Dmitris and his business. Indifex is, after all, a commercial venture, and server resources and bandwidth aren't free of charge -- especially on the scale contemplated for Fedora. Just before I came to work for Red Hat, I owned a small IT business myself, and know that every penny counts! :)
Indeed. We, Fedora Localization Project, will grow day by day but unlikely shrink. If doubt, check Fedora weekly news, new translators joined are listed every two to three weeks. Hosting the system on Fedora home is fair to all.
noriko
Cheers Rudi
On 2011-02-21 03:01:10 PM, noriko wrote:
It won't disturb other teams such as developers and web team by imposing the task for move as well.
Actually, that's not the case - if we upgrade to 1.1, all projects that use Transifex for translations will still have to change their workflow for the new version in the same way that they would have to with moving to transifex.net.
The reason is that since version 1.0, Transifex no longer talks directly to version controls systems - instead they switched to a model where Transifex stores strings in its database and project maintainers pull translated strings into their own repos as part of their workflow.
I still don't understand why some people seem so against switching to transifex.net though :-/
Thanks, Ricky
On 02/21/2011 03:07 PM, Ricky Zhou wrote:
The reason is that since version 1.0, Transifex no longer talks directly to version controls systems - instead they switched to a model where Transifex stores strings in its database and project maintainers pull translated strings into their own repos as part of their workflow.
This is really unfortunate: it removes one of the most useful features of Transifex.
I will investigate whether Red Hat can provide resources to either reincorporate this feature into the version of Transifex that we deploy, or at the very least, automate synching the Transifex database with the fedorahosted repos.
Cheers, Rudi
On Monday, 21 בFebruary 2011 07:32:44 Ruediger Landmann wrote:
On 02/21/2011 03:07 PM, Ricky Zhou wrote:
The reason is that since version 1.0, Transifex no longer talks directly to version controls systems - instead they switched to a model where Transifex stores strings in its database and project maintainers pull translated strings into their own repos as part of their workflow.
This is really unfortunate: it removes one of the most useful features of Transifex.
I'd like to pull this into another direction (which I'll connect with your argument bellow).
The infrastructure team does a huge job, maintaining multitude of systems (web, bodhi, koji, hosted, etc). One thing I didn't see at all during the discussion before the migration is *WHY* transifex was more painfull to maintain than other systems?
An answer to this would not only help Fedora, but also to our upstream. because Fedora represent a use-case of big project which is *not* the upstream. Hypothetical examples for maintenance problems: * Is it the data migration from version to version? (IIRC it was mentioned in the past as blocking/slowing upgrades) -- Than maybe Tx need better tooling for this.
* Maybe many calls about "inaccessible project VCS" (as mentioned by Ricky elsewhere in this thread) caused a lot of churn. In that case, spooling commits (e.g: to a database as in newer Tx) as an interim storage for the data until sent to the final VCS, would alleviate this problem.
[BTW: This is orthognal to the question if the project should *pull* from a database or the data should be *pushed* to the project VCS. Perhaps in the future both modes may be implemented (per-project selection?)]
The point I'm trying to make is that hosting Tx instance can have another benefit to Tx -- a constant presure (and help as well) to improve tools and methods to lower maintenance burden.
However, for this theoretical benefit to materialize, there should be some pre-conditions * Just like with other Fedora software, we should be "First" and use/package new software versions: - Obviously, there's some tradeoff with stability
- But only this way Fedora can help upstream (in terms of bug-reports, extra scripts, feature requests, etc)
- F14 - transifex-0.8.0-0.2.alpha.fc14 :-( Rawhide - transifex-0.9.1-1.fc15 :-( :-(
* If we cannot maintain a working up to date Tx package, this means it's practically orphan: - The gap to upstream would grow until it breaks (seems like that what happened) - Upstream would not get any benefit from this Tx instance and cannot effectively help us.
* Most of the work to fix this will be on the package maintainers since they would need to bridge the gap between the needs/problems of Fedora admins and what currently Tx can provide... - I haven't heard them speak about the issues...
- Maybe co-maintaining it by developers/admins would help a bit (short circuit requirements/problems to the fixes)
- Involving someone from upstream (not in the on-going admin but in the needed fixes to make it easier) would help a lot both sides, but I don't know if they can invest the required time.
So, IMHO, while this thead is on the trans/docs list -- the real question is if the 'devel' people can invest the resources to make Tx a long-term maintainable package -- if not, than we should "outsource" this to transifex.net (and I completely [and sadly] accept your arguments about the dependencies it creates for Fedora -- but an orphan package is an orphan package)
Thanks,
On Mon, Feb 21, 2011 at 4:33 AM, Ruediger Landmann r.landmann@redhat.com wrote: [snip]
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
Does this seem acceptable?
I also want to take this opportunity to thank Dmitris for his extremely generous offer to host this massive project on behalf of Fedora. However, apart from the reasons I gave earlier, I also can't help but feel that this direction would be grossly unfair on Dmitris and his business. Indifex is, after all, a commercial venture, and server resources and bandwidth aren't free of charge -- especially on the scale contemplated for Fedora. Just before I came to work for Red Hat, I owned a small IT business myself, and know that every penny counts! :)
Cheers Rudi
Thanks for the proposal. +1 to run our own instance.
As translator, we just need a running instance. As our current instance is running with issues for at least 1 year, the question is why no discussion between l10n and infra was done before. And I've not seen any request on the trans mailing list to joining the infra...
Translators just need to translate efficiently. This could not be done with the current instance for every projects. The move to txn appears to not be complete (I've at least seen 3 bug reports) but should not take too long. Having more people joining/helping the infra for a week is really great. The most important is to see with the infra how could we handle the transifex instance in a long term, but you, Ruediger, told us that this should not be a problem, thanks! (Guarantee should be discussed with the infra team). Therefor, as a l10n member, the most important is to have a working workflow. Having fas auth is great, but not mandatory.
As a Fedora Project contributor, Fedora running its own instance is better as we have a strong community who do great job. Having the power to decide is better that choosing an alternate solution because we don't have the power.
In an other hand, running our own instance would help Indifex in two ways. First, we won't use their bandwith as told before, and secondly, we would be an example of their product reuse. Having our Open Source software reused is one of the Freedom goal.
Anyway, thanks for the proposal, and thanks to people working on the txn move. We have taken a decision last week... If we want to change our mind, we should do it quickly but this really concern the infra team.
Regards,
The Transifex.net instance appears to be not able to download source file (.pot), that cause translators work more to create a new po or to simply update their local po file; while the fedora one still provides the function to download the pot file.
In my opinion, although the new features provided by v1.1.0 instance are quite awesome (at least for me), there are still some flaws should be fixed as soon as possible to be the new translation platform for Fedora translators.
On Mon, Feb 21, 2011 at 1:04 PM, Tseng, Cheng-Chia pswo10680@gmail.com wrote:
The Transifex.net instance appears to be not able to download source file (.pot).
The English file itself acts as a POT file (source language).
As mentioned previously, all the technical observations reported are characteristics of v1.0, not Transifex.net itself.
-d
On Sun, Feb 20, 2011 at 10:33 PM, Ruediger Landmann r.landmann@redhat.com wrote:
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
Sorry for the slow response -- I wasn't keeping up with email for much of the weekend, and didn't see this thread until this morning. I understand your point here regarding our independence, but I don't see any vendor lock-in here. The software is the same open-source software we'd be running on our intrastructure -- it's just that Indifex has offered to take care of the hosting/upgrades/maintenance of it for us. Because it's open source and we have the ability to host it ourselves at any time, it really comes down to a matter of trust. Personally, I can say that I unequivocally trust Dimitris, because I've seen the work he's done in Fedora both as a contributor and a former member of the Fedora Board.
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
That's fine, but you need to coordinate that with both the Infrastructure team and the rest of the L10N team. Having spoken to the Infrastructure team about this several times over the past few days, I know their first concern is going to be the dedication of these resources. In other words, they're not just looking for someone who can upgrade us to 1.0 (or 1.1-dev) now, but *guaranteed resources* to keep it upgraded and maintained and bugs fixed over the *long haul*.
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
With all respect Rudi, it's not just about the Localization team... We had meetings last week between the L10N team, the Infrastructure team, the Docs team, FESCo, the Fedora Program Manager, and myself. We weighed all the pros and cons of the move, and we decided as a group to move forward with the migration to transifex.net. We migrated the translations to transifex.net last Friday. We've got a deadline of having the transifex client packaged up and ready to go for package maintainers by this coming Friday. Any delay (or switch to another platform) adds additional burden to our L10N team, especially when we're already past the string freeze and into their translation time.
I also want to take this opportunity to thank Dmitris for his extremely generous offer to host this massive project on behalf of Fedora. However, apart from the reasons I gave earlier, I also can't help but feel that this direction would be grossly unfair on Dmitris and his business. Indifex is, after all, a commercial venture, and server resources and bandwidth aren't free of charge -- especially on the scale contemplated for Fedora. Just before I came to work for Red Hat, I owned a small IT business myself, and know that every penny counts! :)
I don't think Dimitris would have made us the offer to host our translations if he would have thought that it would be unfair to Indifex. I agree that Indifex is a commercial venture and that the work they're offering does cost them money, but if Dimitris and company are OK with that, how can I argue against it? On the maintenance/upgrades side of things, that's work they already have to do for their other clients. On the bandwidth side of things, I'm sure they'll yell if their bandwidth costs get too high, and then we'll make a determination on whether to compensate them for bandwidth, move to being self-hosted again, or find some other solution.
May I also suggest that we move this discussion to the logistics mailing list, since the discussion needs to include more people than just the Docs or the Translation teams?
-- Jared Smith Fedora Project LEader
[note: CCed to logistics list as suggested; see below]
On 02/22/2011 03:02 AM, Jared K. Smith wrote:
On Sun, Feb 20, 2011 at 10:33 PM, Ruediger Landmann r.landmann@redhat.com wrote:
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
Sorry for the slow response -- I wasn't keeping up with email for much of the weekend, and didn't see this thread until this morning. I understand your point here regarding our independence, but I don't see any vendor lock-in here. The software is the same open-source software we'd be running on our intrastructure -- it's just that Indifex has offered to take care of the hosting/upgrades/maintenance of it for us. Because it's open source and we have the ability to host it ourselves at any time, it really comes down to a matter of trust. Personally, I can say that I unequivocally trust Dimitris, because I've seen the work he's done in Fedora both as a contributor and a former member of the Fedora Board.
Thanks Jared; and sorry for my slow reply too. I don't think anything is gained by further haste at this point, and I've been taking some time to think through my responses.
First, can we please clear the air of any notion of vendor lock-in? That has never been a concern of mine, and I hope that I have not said anything to suggest that it was. I think we can agree that you can be dependent on someone or something even without being locked in. You otherwise understand what I'm saying about dependence, so really, the point of contention is "only" whether in this case, the dependence is good, bad, or indifferent! :)
Second, I'd like to put the question of trust aside as well. Dimitris has certainly established his credentials and bona fides within our community. When you suggest that the move to Transifex.net comes down to "a matter of trust" you risk reframing the discussion from "do we think that moving Fedora's translation infrastructure to an external provider is a good idea or not?" to "do we trust Dimitris or not?" It's just not fair to personalize the discussion that way, and I would hate to think that anybody would equate "doesn't support the move to transifex.net" with "doesn't trust Dimitris".
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
That's fine, but you need to coordinate that with both the Infrastructure team and the rest of the L10N team. Having spoken to the Infrastructure team about this several times over the past few days, I know their first concern is going to be the dedication of these resources. In other words, they're not just looking for someone who can upgrade us to 1.0 (or 1.1-dev) now, but *guaranteed resources* to keep it upgraded and maintained and bugs fixed over the *long haul*.
Of course! :) I am working on getting something formalized in this direction. Are the terms of the Fedora Project's service-level agreement with Indifex a matter of public record? (and will performance reports be publicly available to the community?)
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
With all respect Rudi, it's not just about the Localization team... We had meetings last week between the L10N team, the Infrastructure team, the Docs team, FESCo, the Fedora Program Manager, and myself. We weighed all the pros and cons of the move, and we decided as a group to move forward with the migration to transifex.net. We migrated the translations to transifex.net last Friday. We've got a deadline of having the transifex client packaged up and ready to go for package maintainers by this coming Friday. Any delay (or switch to another platform) adds additional burden to our L10N team, especially when we're already past the string freeze and into their translation time.
Understood, and I agree that added delay and uncertainty at this point would pose a significant and unfair burden to translators. I'm sorry that other options were not made available earlier. Thank you very much for raising the issue with the Board (as you related in your follow-up email, not quoted here) and I concur that it makes more sense to revisit this after F15 is out the door. Your firm hand on the rudder is appreciated :)
I'm a little confused by the nature of the meetings you're talking about though. I was only at the docs meeting, and that didn't seem to include any weighing up of options. For that matter, the L10n meeting didn't either, based on the logs -- it reads to me more like a fait accompli.
On the subject of the L10n meeting: I'm in a difficult position. I'm proud to number some of the people who participated in that meeting amongst my friends, so I *really* don't want to single out specific people or comments in the log. Also, IRC doesn't capture the nuances of human communication very well and I can't discount the possibility that I'm badly misreading the tone of the meeting. So, all I can do is invite anyone who's interested to go and read the log at http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
One specific thing in there that does confuse me though is the vote that occurs about 96 minutes into the meeting; I don't really understand what was going on there or how it fits together with the idea that the decision about where to host Fedora's translation infrastructure wasn't just up to the Fedora Localization Project. I'd appreciate clarification from anyone who was at the meeting.
I also want to take this opportunity to thank Dmitris for his extremely generous offer to host this massive project on behalf of Fedora. However, apart from the reasons I gave earlier, I also can't help but feel that this direction would be grossly unfair on Dmitris and his business. Indifex is, after all, a commercial venture, and server resources and bandwidth aren't free of charge -- especially on the scale contemplated for Fedora. Just before I came to work for Red Hat, I owned a small IT business myself, and know that every penny counts! :)
I don't think Dimitris would have made us the offer to host our translations if he would have thought that it would be unfair to Indifex. I agree that Indifex is a commercial venture and that the work they're offering does cost them money, but if Dimitris and company are OK with that, how can I argue against it? On the maintenance/upgrades side of things, that's work they already have to do for their other clients. On the bandwidth side of things, I'm sure they'll yell if their bandwidth costs get too high, and then we'll make a determination on whether to compensate them for bandwidth, move to being self-hosted again, or find some other solution.
Great :) Like I said, it's a very generous offer by Dmitris and Indifex, and whether or not I personally agree with the move, I applaud the commitment that it shows.
So there's room in the Fedora budget to compensate Indifex if the need arises?
May I also suggest that we move this discussion to the logistics mailing list, since the discussion needs to include more people than just the Docs or the Translation teams?
of course -- CCing them in.
In conclusion, I'm really conflicted here, because on the one hand I don't want to strain friendships or to be obstructionist, but on the other hand I feel compelled to speak up about a decision (and a process) that disturbs me.
Cheers Rudi
Caveat here: I wasn't in any meetings, had no foreknowledge of anything, and am not involved in any of these activities. I'm an observer who just read that IRC log and some mailing list threads over the last few days. I'm going to attempt to keep my reply within the confines of these recent activities and my general knowledge of how to do things the open source way.
The IRC log in question:
http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
On Thu, Feb 24, 2011 at 04:32:37PM +1000, Ruediger Landmann wrote:
I'm a little confused by the nature of the meetings you're talking about though. I was only at the docs meeting, and that didn't seem to include any weighing up of options. For that matter, the L10n meeting didn't either, based on the logs -- it reads to me more like a fait accompli.
I think you are right, and there was clearly confusion about the meaning of the vote. My reading is that everyone understood what they were voting for at the end. It was clear people felt it was rushed, uninformed, and risky to proceed. However, the plans do seem to have seen adjustment in response to L10n concerns.
I read the results of the L10n meeting as:
Infra: "We really hate to do this, but we have no choice and no time to do anything other than move all L10n services to Tx.net immediately. Sorry about the late notice."
L10n: "Wow, that is really surprising, I don't know if I support this all the way and want some protection in place. I see it's too late to do anything else for the F15 cycle so I'll support the move with the agreement that we revisit this discussion as many of us would prefer to have L10n services hosted by the Fedora Project if we can."
From what I read in that log, the lateness in the F15 cycle meant a program mangement and project leadership decision had to be made, which was really to support what Infrastructure had already decided made the most sense. Bringing it all-of-a-sudden to L10n with a mysteriously-valuable vote in the wings seemed to add to the confusion.
However, do I see that the whole discussion has raised some items that were not fait accompli, which I cover below.
On the subject of the L10n meeting: I'm in a difficult position. I'm proud to number some of the people who participated in that meeting amongst my friends, so I *really* don't want to single out specific people or comments in the log. Also, IRC doesn't capture the nuances of human communication very well and I can't discount the possibility that I'm badly misreading the tone of the meeting. So, all I can do is invite anyone who's interested to go and read the log at http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
One specific thing in there that does confuse me though is the vote that occurs about 96 minutes into the meeting; I don't really understand what was going on there or how it fits together with the idea that the decision about where to host Fedora's translation infrastructure wasn't just up to the Fedora Localization Project. I'd appreciate clarification from anyone who was at the meeting.
Thank you for your email, it is an excellent summary of the situational concerns, has some good resolution, and shines light on the path we can keep moving down.
In conclusion, I'm really conflicted here, because on the one hand I don't want to strain friendships or to be obstructionist, but on the other hand I feel compelled to speak up about a decision (and a process) that disturbs me.
Definitely there was some process breakdown and some lack-of-process.
It seems that it wasn't an active open community discussion between Infrastructure and affected teams about problems with maintaining translate.fp.org and how to fix them. This all could have been discussed over the preceding months, presuming that were possible ... and I am going to presume it wasn't, that we are here based on a series of best-efforts and best-will from people involved. Does that make sense?
Jared and Paul said in the meeting log multiple times that we needed to avoid people being surprised by the situation, but unfortunately that wasn't very likely. The timing involved made it a certainty that some people were going to be squeezed, surprised, and upset.
I perceive the following items as fait accompli before that meeting happened:
* Fedora Infrastructure decided they could no longer provide translation services.
* To meet their service obligations, FI put in place a plan to move translation services to Transifex.net.
* Fedora Project leadership were essentially in agreemen with that plan.
I didn't see the following items as fait accompli before that meeting:
* Future of hosting our own translation tool of any kind on fedoraproject.org. Clearly we can revisit this decision, clearly people wanted to.
* Ability for resourceful people to step forward and make it possible to either not move for F15 or move back for F16. For example, you seem to have responded to this by seeking new, on-going resource commitments.
* Commitment of L10n leadership toward any particular plan. People came in to that meeting with different opinions and agendas, but seemed to come to consensus by the end.
Community supported infrastructure doesn't have to be of a lesser service level overall, but things tend to be less formal across the board about change impact on community participants.
One lesson to pull from this situation is for *every* service provider (which inclues L10n, Docs, Infrastructure, et al) to have a change management process in place that:
1. Exposes problems (needs for change) early and often. 2. Encourages discussion and work so decisions (why, how) are visible to all affected. 3. Makes sure affected teams are not surprised by developments.
I have seen the Fedora Program Manager and various teams work this process manually over the years, but I'm not sure how many teams have a change management process in place so they can reduce surprise with other Fedora teams?
- Karsten
On Thu, Feb 24, 2011 at 11:08 PM, Karsten Wade kwade@redhat.com wrote:
Caveat here: I wasn't in any meetings, had no foreknowledge of anything, and am not involved in any of these activities. I'm an observer who just read that IRC log and some mailing list threads over the last few days. I'm going to attempt to keep my reply within the confines of these recent activities and my general knowledge of how to do things the open source way.
The IRC log in question:
http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
On Thu, Feb 24, 2011 at 04:32:37PM +1000, Ruediger Landmann wrote:
I'm a little confused by the nature of the meetings you're talking about though. I was only at the docs meeting, and that didn't seem to include any weighing up of options. For that matter, the L10n meeting didn't either, based on the logs -- it reads to me more like a fait accompli.
I think you are right, and there was clearly confusion about the meaning of the vote. My reading is that everyone understood what they were voting for at the end. It was clear people felt it was rushed, uninformed, and risky to proceed. However, the plans do seem to have seen adjustment in response to L10n concerns.
I read the results of the L10n meeting as:
Infra: "We really hate to do this, but we have no choice and no time to do anything other than move all L10n services to Tx.net immediately. Sorry about the late notice."
L10n: "Wow, that is really surprising, I don't know if I support this all the way and want some protection in place. I see it's too late to do anything else for the F15 cycle so I'll support the move with the agreement that we revisit this discussion as many of us would prefer to have L10n services hosted by the Fedora Project if we can."
From what I read in that log, the lateness in the F15 cycle meant a program mangement and project leadership decision had to be made, which was really to support what Infrastructure had already decided made the most sense. Bringing it all-of-a-sudden to L10n with a mysteriously-valuable vote in the wings seemed to add to the confusion.
However, do I see that the whole discussion has raised some items that were not fait accompli, which I cover below.
On the subject of the L10n meeting: I'm in a difficult position. I'm proud to number some of the people who participated in that meeting amongst my friends, so I *really* don't want to single out specific people or comments in the log. Also, IRC doesn't capture the nuances of human communication very well and I can't discount the possibility that I'm badly misreading the tone of the meeting. So, all I can do is invite anyone who's interested to go and read the log at http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
One specific thing in there that does confuse me though is the vote that occurs about 96 minutes into the meeting; I don't really understand what was going on there or how it fits together with the idea that the decision about where to host Fedora's translation infrastructure wasn't just up to the Fedora Localization Project. I'd appreciate clarification from anyone who was at the meeting.
Thank you for your email, it is an excellent summary of the situational concerns, has some good resolution, and shines light on the path we can keep moving down.
In conclusion, I'm really conflicted here, because on the one hand I don't want to strain friendships or to be obstructionist, but on the other hand I feel compelled to speak up about a decision (and a process) that disturbs me.
Definitely there was some process breakdown and some lack-of-process.
It seems that it wasn't an active open community discussion between Infrastructure and affected teams about problems with maintaining translate.fp.org and how to fix them. This all could have been discussed over the preceding months, presuming that were possible ... and I am going to presume it wasn't, that we are here based on a series of best-efforts and best-will from people involved. Does that make sense?
Jared and Paul said in the meeting log multiple times that we needed to avoid people being surprised by the situation, but unfortunately that wasn't very likely. The timing involved made it a certainty that some people were going to be squeezed, surprised, and upset.
I perceive the following items as fait accompli before that meeting happened:
- Fedora Infrastructure decided they could no longer provide
translation services.
- To meet their service obligations, FI put in place a plan to move
translation services to Transifex.net.
- Fedora Project leadership were essentially in agreemen with that
plan.
I didn't see the following items as fait accompli before that meeting:
- Future of hosting our own translation tool of any kind on
fedoraproject.org. Clearly we can revisit this decision, clearly people wanted to.
- Ability for resourceful people to step forward and make it possible
to either not move for F15 or move back for F16. For example, you seem to have responded to this by seeking new, on-going resource commitments.
- Commitment of L10n leadership toward any particular plan. People
came in to that meeting with different opinions and agendas, but seemed to come to consensus by the end.
Community supported infrastructure doesn't have to be of a lesser service level overall, but things tend to be less formal across the board about change impact on community participants.
One lesson to pull from this situation is for *every* service provider (which inclues L10n, Docs, Infrastructure, et al) to have a change management process in place that:
- Exposes problems (needs for change) early and often.
- Encourages discussion and work so decisions (why, how) are visible
to all affected. 3. Makes sure affected teams are not surprised by developments.
Yes, we (the infra and trans) should have discussed about our transifex instance more seriously before deciding that it is *really* to late to take time
I have seen the Fedora Program Manager and various teams work this process manually over the years, but I'm not sure how many teams have a change management process in place so they can reduce surprise with other Fedora teams?
- Karsten
--
As seen now that we have started using Transifex.net, is that using the same service as other communities helps collaborate. It is easier to see and join other projects (in both ways) when you can see their file and how their are managed.
2011/2/24 Karsten Wade kwade@redhat.com:
Caveat here: I wasn't in any meetings, had no foreknowledge of anything, and am not involved in any of these activities. I'm an observer who just read that IRC log and some mailing list threads over the last few days. I'm going to attempt to keep my reply within the confines of these recent activities and my general knowledge of how to do things the open source way.
The IRC log in question:
http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
On Thu, Feb 24, 2011 at 04:32:37PM +1000, Ruediger Landmann wrote:
I'm a little confused by the nature of the meetings you're talking about though. I was only at the docs meeting, and that didn't seem to include any weighing up of options. For that matter, the L10n meeting didn't either, based on the logs -- it reads to me more like a fait accompli.
I think you are right, and there was clearly confusion about the meaning of the vote. My reading is that everyone understood what they were voting for at the end. It was clear people felt it was rushed, uninformed, and risky to proceed. However, the plans do seem to have seen adjustment in response to L10n concerns.
I read the results of the L10n meeting as:
Infra: "We really hate to do this, but we have no choice and no time to do anything other than move all L10n services to Tx.net immediately. Sorry about the late notice."
Hmm then I was not communicating very clearly:
The issue was that transifex has been an ongoing problem for the following reasons:
1) It is a moving target. Development upstream is fast moving and adding new features that translators want.
2) We are really really behind on upgrades. There have been multiple groups who have stepped up, started to do it and then had real life hit them with some sort of curve ball. So what started out as 0.7 -> 0.8 became 0.7 -> 0.9 and now would have to be 0.7 -> 1.1. We had multiple people who for the last 3-4 months have said "We would be happy to upgrade, but we aren't really able to do more than that."
3) We could have kept the old transifex going but this seemed to cause more problems than it solved. There have been many items where people were 'hamstrung' with the current software and wanted us to move to something new.
4) In looking at Infrastructures current status I realized that we were spending a lot of time on triage and not moving forward with projects (and in some cases were moving backwards). We looked at what our core missions were and what we could have other people do better. And it meant pruning back stuff we were not doing well so we could focus on getting things done elsewhere.
Now where we did not hand off things well.
1) We asked people in L10N and docs about it but did not make sure that was communicated clearly with their groups. That meant we ended up with thinking we had agreement but didn't.
2) Web software is hard to keep up with unless people stick to it. Volunteer infrastructure scales well for certain items but has had problems with long term projects. [This is no different than dealing with drupal, plone, most Ruby on Rails etc. If your software is updating every 3-6 months it is hard to deploy in a production environment unless you have dedicated people to keep up with it.]
3) As I said in my blog post on this and some other items:
Now usually after a post like this occurs, we get a bunch of volunteers who will say "We can take this over." I am asking people not to do this, because frankly volunteering under pressure usually means leaving when the pressure is gone. We have gone this route several times before, and its not something I think is sustainable.
We will look for volunteers who can replant the services, document them, build out a staging and production service and train OTHER volunteers on them so that any replacement service has a chance of lasting.
On Thu, Feb 24, 2011 at 05:17:00PM -0700, Stephen John Smoogen wrote:
The issue was that transifex has been an ongoing problem for the following reasons:
<snip important list of reasons/details>
Thanks for providing those details. I meant, and wrote it poorly I'm sure, that I presume that the situation was much as you described, but in the end there were people who did not feel/get communicated to. At that point, Infra and others were saying, "OK, sorry if you didn't hear about this before, it's been a long-standing problem, and we need to solve it now before the barn burns down."
So, sorry for characterizing the communication as poor. I think what I'm seeing could benefit from some change management that all know about. A lot of times we have to result to a change management list that goes something like, "OK, ask $this_list_of_individuals_I_can_think_of, then email $this_list_of_mailing_lists_I_can_think_of, and write a blog post."
Anyway, I'm sure there is a not-too-much-bureacracy way to do this. I started this ...
https://fedoraproject.org/wiki/Change_management
... I'm sure there are others who deal with that all the time around here, maybe there are some existing processes we can adopt, incorporate, hug, etc.
Thanks,
- Karsten
Hey all,
I want to say an enormous thank-you to the logistics folks who have weighed into this thread -- your replies have been more than generous. In particular, I want to thank Karsten, abadger, Smooge, and David Nalley -- plus Ricky earlier in the thread -- for your thoughtful and helpful insights into the Transifex migration and what led up to it. It's times like these that I wish we had some formal way of recognizing awesomeness in Fedora!
I don't really have anything more to add right now, but wanted to acknowledge each of you guys rather than just let the thread die without extending my gratitude :)
I also want to reaffirm that even if I'm (evidently!) not happy about the decision, I'm fully committed to making it work wherever it touches what I do in Fedora, and I'm behind our leadership 100% here :)
I look forward to revisiting the issue once we've got F15 out the door!
Cheers Rudi
Stephen John Smoogen さんは書きました:
2011/2/24 Karsten Wade kwade@redhat.com:
Caveat here: I wasn't in any meetings, had no foreknowledge of anything, and am not involved in any of these activities. I'm an observer who just read that IRC log and some mailing list threads over the last few days. I'm going to attempt to keep my reply within the confines of these recent activities and my general knowledge of how to do things the open source way.
The IRC log in question:
http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
On Thu, Feb 24, 2011 at 04:32:37PM +1000, Ruediger Landmann wrote:
I'm a little confused by the nature of the meetings you're talking about though. I was only at the docs meeting, and that didn't seem to include any weighing up of options. For that matter, the L10n meeting didn't either, based on the logs -- it reads to me more like a fait accompli.
I think you are right, and there was clearly confusion about the meaning of the vote. My reading is that everyone understood what they were voting for at the end. It was clear people felt it was rushed, uninformed, and risky to proceed. However, the plans do seem to have seen adjustment in response to L10n concerns.
I read the results of the L10n meeting as:
Infra: "We really hate to do this, but we have no choice and no time to do anything other than move all L10n services to Tx.net immediately. Sorry about the late notice."
Hi Stephen
First of all, I like to express our sincere thanks from our bottom of hearts to you and all your team members for every effort and time spent for L10n. Now please allow me to ask further help to understand a little more the situation where we are standing. It will help to establish an exit plan in the future.
Hmm then I was not communicating very clearly:
The issue was that transifex has been an ongoing problem for the following reasons:
- It is a moving target. Development upstream is fast moving and
adding new features that translators want.
It seems natural that every software is moving better, adding new features. However if a feature newly to be added may interfere existing function, as a user translator, I wish not to have a new feature added.
- We are really really behind on upgrades. There have been multiple
groups who have stepped up, started to do it and then had real life hit them with some sort of curve ball. So what started out as 0.7 -> 0.8 became 0.7 -> 0.9 and now would have to be 0.7 -> 1.1. We had multiple people who for the last 3-4 months have said "We would be happy to upgrade, but we aren't really able to do more than that."
I see. So not enough resource can be assigned to such **frequent upgrade tasks from long term view.
What I am understanding is that the problems we are encountering are caused by older version, and that the solution is to only upgrade. Is this correct understanding? Please let me make the point clear that L10n just wants stable working version, not necessarily keep upgraded.
What if we upgrade less often?
- We could have kept the old transifex going but this seemed to cause
more problems than it solved. There have been many items where people were 'hamstrung' with the current software and wanted us to move to something new.
The old transifex above means v0.7 or v0.9.1? Who is 'people' and what 'items' make these people hamstrung?
At least, there were actually v0.9.1 up on the staging server and running, which beckerde and lots of people put their time, blood, sweat and tears [1]. Many of language teams leaders who put themselves in CC had been watching this ticket and hoping/expecting the v0.9.1 system to be implemented onto production. What it the cause to make this ticket abandoned?
Thanks in advance for your help. noriko
[1]:https://fedorahosted.org/fedora-infrastructure/ticket/2389
- In looking at Infrastructures current status I realized that we
were spending a lot of time on triage and not moving forward with projects (and in some cases were moving backwards). We looked at what our core missions were and what we could have other people do better. And it meant pruning back stuff we were not doing well so we could focus on getting things done elsewhere.
Now where we did not hand off things well.
- We asked people in L10N and docs about it but did not make sure
that was communicated clearly with their groups. That meant we ended up with thinking we had agreement but didn't.
- Web software is hard to keep up with unless people stick to it.
Volunteer infrastructure scales well for certain items but has had problems with long term projects. [This is no different than dealing with drupal, plone, most Ruby on Rails etc. If your software is updating every 3-6 months it is hard to deploy in a production environment unless you have dedicated people to keep up with it.]
- As I said in my blog post on this and some other items:
Now usually after a post like this occurs, we get a bunch of volunteers who will say "We can take this over." I am asking people not to do this, because frankly volunteering under pressure usually means leaving when the pressure is gone. We have gone this route several times before, and its not something I think is sustainable.
We will look for volunteers who can replant the services, document them, build out a staging and production service and train OTHER volunteers on them so that any replacement service has a chance of lasting.
On Thu, Feb 24, 2011 at 02:08:40PM -0800, Karsten Wade wrote:
Definitely there was some process breakdown and some lack-of-process.
It seems that it wasn't an active open community discussion between Infrastructure and affected teams about problems with maintaining translate.fp.org and how to fix them. This all could have been discussed over the preceding months, presuming that were possible ... and I am going to presume it wasn't, that we are here based on a series of best-efforts and best-will from people involved. Does that make sense?
So... you'll need to contact mmcgrath for exactly where, with whom, and when previous discussions took place but discussion had been taking place for quite a while. A lot of people realized there was an issue when this ticket took 9 months to resolve: https://fedorahosted.org/fedora-infrastructure/ticket/1455
Enough that gomix, beckerde, other translators, and I discussed the situation at FUDCon Chile last year and I opened this ticket: https://fedorahosted.org/fedora-infrastructure/ticket/2277
The first meeting that we (infra) discussed that ticket at, mmcgrath said that he'd tried but failed to find someone to maintain transifex in infra from the l10n team. He and I tried to think of someone that we knew personally that could do the job and via email got in touch with beckerde who agreed to work on packaging and migration of the new transifex.
Since beckerde was new to Fedora packaging and transifex dependencies had changed it took a while to get things working but with the help of other latam packagers we got packaging sorted out eventually and started to test upgrades on the infrastructure staging servers. The version that's being worked on is an older version because newer versions of transifex would change the translation workflow (the recent talks have made clear that the change in workflow is mainly for the developers of the translated software rather than the translators.)
{{A side thread to this story: In the F14 time frame (ticket 1455 time frame), the translation teams made some valid noise about the problems that the version of transifex we were running were causing them. At that time, glezos, stickster, some people from l10n and infra analyzed the possibility of moving to transifex.net and decided that it was possible but were divided about the desirability. We were able to upgrade the FI instance of transifex which deferred the question.}}
Sometime between the tests on stg and fudcon some of infra starts worrying about how we're going to continue maintaining transifex. beckerde is signing up to work on packaging the software and deploying it but we're still running several versions behind and we don't have in-house knowledge on how to fix issues in the code. Moving to the newest version is caught in the workflow changing problem that, since infra isn't involved in using transifex, none of us know what is changing or how to approach l10n about changing their workflow to accomodate it.
{{Next side thread: mmcgrath leaves as infrastructure leader. This leaves us shorthanded as we were already running close to capacity and mmcgrath was also a good community leader who was able to entice and induct volunteers.}}
At FUDCon, smooge, skvidal, ricky, CodeBlock meet with igorps and some other translators that are present and talk about moving off of Fedora hosting transifex if glezos still wants to host us. We talk about a gradual shift at that time. Later, infrastructure members talk to glezos on IRC and more with each other.
{{Third side note: At FUDCon, infrastructure realizes how deeply overcommitted we are. People at "The Next Big Infrastructure Project" were excited about a bunch of cool ideas for new services but we realized that to do any of them, we needed to either get rid of some of our present responsibilities or get new long-term sysadmins to help out.}}
On IRC, post-FUDCon, we talk with glezos and firm up plans a bit more. Someone convinces everyone else that moving a little at a time doesn't help anyone because there's a lot more confusion if we have two separate places to translate at, two procedures to integrate the translations with software, etc. Fedora Infrastructure has a meeting where we figure out how we feel about migrating transifex service to tx.net. We're in favour. glezos to carry the idea for coordination with the l10n team.
At this point things start moving fast. Content is synced to transifex.net for a Proof of Concept, meeting with l10n is setup to talk about migrating. Decision is made to migrate pre-F15 because the FI-hosted transifex is too painful, coordination with developers who will need to pull the translations on newer versions of transifex is talked about, duties are assigned for migrating, setting up teams, packaging the client-side tools for developers, etc. That brings us pretty much to the present.
What I draw from all this is that:
1) Although communication was present, it didn't involve everyone touched by the change. That's pretty hard to achieve in any circumstance but we could try to make it better. From infra's point of view, transifex was being provided by us to the Fedora l10n team which is not entirely accurate. So there needs to be a way to figure out the chain of dependent people.
2) In some ways, people were just waiting on a decision. Fedora Infrastructure was not able to update to the newest transifex because of workflow changes. However, once it was decided that Fedora Infrastructure, therefore, couldn't upgrade (or fix) transifex at all, it was easy and quick for people on l10n to make a decision about changing workflow to get more reliable service.
3) It seems that maintainance is harder to recruit people to work on than a new direction. That new direction can even be a continuation of the current direction (move to a newer transifex on transifex.net) as long as it's seen as a decision needing certain definite actions.
Jared and Paul said in the meeting log multiple times that we needed to avoid people being surprised by the situation, but unfortunately that wasn't very likely. The timing involved made it a certainty that some people were going to be squeezed, surprised, and upset.
I perceive the following items as fait accompli before that meeting happened:
Fedora Infrastructure decided they could no longer provide translation services.
To meet their service obligations, FI put in place a plan to move translation services to Transifex.net.
Fedora Project leadership were essentially in agreemen with that plan.
I didn't see the following items as fait accompli before that meeting:
Future of hosting our own translation tool of any kind on fedoraproject.org. Clearly we can revisit this decision, clearly people wanted to.
Ability for resourceful people to step forward and make it possible to either not move for F15 or move back for F16. For example, you seem to have responded to this by seeking new, on-going resource commitments.
Commitment of L10n leadership toward any particular plan. People came in to that meeting with different opinions and agendas, but seemed to come to consensus by the end.
One note here -- in the meeting skvidal made a statement about what would happen if we didn't move to transifex.net which was both harsh and true. But it shows that there's another thing that wasn't quite a fait accompli:
* Infrastructure could have continued to host a transifex instance but we could not continue to support it (with updates, with fixes for any of the numerous open bugs, with the ability to make it more reliable, etc). skvidal's projection was that such a strategy, while possible, would eventually lead to our instance of transifex preventing work from being done at a time when nothing could be done about it making everybody upset.
Community supported infrastructure doesn't have to be of a lesser service level overall, but things tend to be less formal across the board about change impact on community participants.
One lesson to pull from this situation is for *every* service provider (which inclues L10n, Docs, Infrastructure, et al) to have a change management process in place that:
- Exposes problems (needs for change) early and often.
- Encourages discussion and work so decisions (why, how) are visible to all affected.
- Makes sure affected teams are not surprised by developments.
I'd like to see an infrastructure threat board. Here's an idea of how that would work: The threat board would have services that have no dedicated person working on them as level red, things that have one or two person working on them as level amber, less than five in yellow, and green at five or more. A standing policy would be that things in amber or less are in danger of being dropped and we need to work on how we're going to gracefully drop, outsource, or reassign-drum up help for them (for instance, we can't very well drop koji support so if it was in amber, someone would have to come across from something else that they were doing to work on that). Perhaps once a month, we'd post services that are not green to fedora-devel-announce and if we didn't get its levels to rise in X amount of time, we'd be free to enact our contingency plans if we chose.
-Toshio
[top-posting to retain the quoted mail in entirety]
Thank you Toshio for the detailed information. This does provide some clarity about the events in the background that eventually led to the decision. Since we are already into the transition phase, further debate on the 'hows' and 'whys' and 'so thats what it really was' would not serve much purpose besides adding to the noise.
However, since we do expect to review the decision and explore the possibility of returning to a Fedora hosted infrastructure, we may as well ensure that we do not repeat the mistakes, especially that of communicating. As opposed to the individuals from the FLP, the FLSCo, an elected group of representatives from the FLP did not seem to figure anywhere during all this (unreported) discussion. As a result, an established communication channel within the FLP was completely ignored or not utilized.
The 'threat board' is perhaps another good thing to have in the future. With red signs flashing all over the FLSCo and FLP could have pushed for discussion much earlier. It would also allow individual project teams to check back on the general health of the tools that they use.
Thank you for your patience and hopefully we can see a much stable translation infrastructure in place for the FLP.
regards Runa
On শুক্রবার 25 ফেব্রুয়ারি 2011 06:14 , Toshio Kuratomi wrote:
On Thu, Feb 24, 2011 at 02:08:40PM -0800, Karsten Wade wrote:
Definitely there was some process breakdown and some lack-of-process.
It seems that it wasn't an active open community discussion between Infrastructure and affected teams about problems with maintaining translate.fp.org and how to fix them. This all could have been discussed over the preceding months, presuming that were possible ... and I am going to presume it wasn't, that we are here based on a series of best-efforts and best-will from people involved. Does that make sense?
So... you'll need to contact mmcgrath for exactly where, with whom, and when previous discussions took place but discussion had been taking place for quite a while. A lot of people realized there was an issue when this ticket took 9 months to resolve: https://fedorahosted.org/fedora-infrastructure/ticket/1455
Enough that gomix, beckerde, other translators, and I discussed the situation at FUDCon Chile last year and I opened this ticket: https://fedorahosted.org/fedora-infrastructure/ticket/2277
The first meeting that we (infra) discussed that ticket at, mmcgrath said that he'd tried but failed to find someone to maintain transifex in infra from the l10n team. He and I tried to think of someone that we knew personally that could do the job and via email got in touch with beckerde who agreed to work on packaging and migration of the new transifex.
Since beckerde was new to Fedora packaging and transifex dependencies had changed it took a while to get things working but with the help of other latam packagers we got packaging sorted out eventually and started to test upgrades on the infrastructure staging servers. The version that's being worked on is an older version because newer versions of transifex would change the translation workflow (the recent talks have made clear that the change in workflow is mainly for the developers of the translated software rather than the translators.)
{{A side thread to this story: In the F14 time frame (ticket 1455 time frame), the translation teams made some valid noise about the problems that the version of transifex we were running were causing them. At that time, glezos, stickster, some people from l10n and infra analyzed the possibility of moving to transifex.net and decided that it was possible but were divided about the desirability. We were able to upgrade the FI instance of transifex which deferred the question.}}
Sometime between the tests on stg and fudcon some of infra starts worrying about how we're going to continue maintaining transifex. beckerde is signing up to work on packaging the software and deploying it but we're still running several versions behind and we don't have in-house knowledge on how to fix issues in the code. Moving to the newest version is caught in the workflow changing problem that, since infra isn't involved in using transifex, none of us know what is changing or how to approach l10n about changing their workflow to accomodate it.
{{Next side thread: mmcgrath leaves as infrastructure leader. This leaves us shorthanded as we were already running close to capacity and mmcgrath was also a good community leader who was able to entice and induct volunteers.}}
At FUDCon, smooge, skvidal, ricky, CodeBlock meet with igorps and some other translators that are present and talk about moving off of Fedora hosting transifex if glezos still wants to host us. We talk about a gradual shift at that time. Later, infrastructure members talk to glezos on IRC and more with each other.
{{Third side note: At FUDCon, infrastructure realizes how deeply overcommitted we are. People at "The Next Big Infrastructure Project" were excited about a bunch of cool ideas for new services but we realized that to do any of them, we needed to either get rid of some of our present responsibilities or get new long-term sysadmins to help out.}}
On IRC, post-FUDCon, we talk with glezos and firm up plans a bit more. Someone convinces everyone else that moving a little at a time doesn't help anyone because there's a lot more confusion if we have two separate places to translate at, two procedures to integrate the translations with software, etc. Fedora Infrastructure has a meeting where we figure out how we feel about migrating transifex service to tx.net. We're in favour. glezos to carry the idea for coordination with the l10n team.
At this point things start moving fast. Content is synced to transifex.net for a Proof of Concept, meeting with l10n is setup to talk about migrating. Decision is made to migrate pre-F15 because the FI-hosted transifex is too painful, coordination with developers who will need to pull the translations on newer versions of transifex is talked about, duties are assigned for migrating, setting up teams, packaging the client-side tools for developers, etc. That brings us pretty much to the present.
What I draw from all this is that:
- Although communication was present, it didn't involve everyone touched by
the change. That's pretty hard to achieve in any circumstance but we could try to make it better. From infra's point of view, transifex was being provided by us to the Fedora l10n team which is not entirely accurate. So there needs to be a way to figure out the chain of dependent people.
- In some ways, people were just waiting on a decision. Fedora
Infrastructure was not able to update to the newest transifex because of workflow changes. However, once it was decided that Fedora Infrastructure, therefore, couldn't upgrade (or fix) transifex at all, it was easy and quick for people on l10n to make a decision about changing workflow to get more reliable service.
- It seems that maintainance is harder to recruit people to work on than a
new direction. That new direction can even be a continuation of the current direction (move to a newer transifex on transifex.net) as long as it's seen as a decision needing certain definite actions.
Jared and Paul said in the meeting log multiple times that we needed to avoid people being surprised by the situation, but unfortunately that wasn't very likely. The timing involved made it a certainty that some people were going to be squeezed, surprised, and upset.
I perceive the following items as fait accompli before that meeting happened:
- Fedora Infrastructure decided they could no longer provide translation
services.
- To meet their service obligations, FI put in place a plan to move
translation services to Transifex.net.
- Fedora Project leadership were essentially in agreemen with that plan.
I didn't see the following items as fait accompli before that meeting:
- Future of hosting our own translation tool of any kind on
fedoraproject.org. Clearly we can revisit this decision, clearly people wanted to.
- Ability for resourceful people to step forward and make it possible to
either not move for F15 or move back for F16. For example, you seem to have responded to this by seeking new, on-going resource commitments.
- Commitment of L10n leadership toward any particular plan. People came in
to that meeting with different opinions and agendas, but seemed to come to consensus by the end.
One note here -- in the meeting skvidal made a statement about what would happen if we didn't move to transifex.net which was both harsh and true. But it shows that there's another thing that wasn't quite a fait accompli:
- Infrastructure could have continued to host a transifex instance but we
could not continue to support it (with updates, with fixes for any of the numerous open bugs, with the ability to make it more reliable, etc). skvidal's projection was that such a strategy, while possible, would eventually lead to our instance of transifex preventing work from being done at a time when nothing could be done about it making everybody upset.
Community supported infrastructure doesn't have to be of a lesser service level overall, but things tend to be less formal across the board about change impact on community participants.
One lesson to pull from this situation is for *every* service provider (which inclues L10n, Docs, Infrastructure, et al) to have a change management process in place that:
- Exposes problems (needs for change) early and often. 2. Encourages
discussion and work so decisions (why, how) are visible to all affected. 3. Makes sure affected teams are not surprised by developments.
I'd like to see an infrastructure threat board. Here's an idea of how that would work: The threat board would have services that have no dedicated person working on them as level red, things that have one or two person working on them as level amber, less than five in yellow, and green at five or more. A standing policy would be that things in amber or less are in danger of being dropped and we need to work on how we're going to gracefully drop, outsource, or reassign-drum up help for them (for instance, we can't very well drop koji support so if it was in amber, someone would have to come across from something else that they were doing to work on that). Perhaps once a month, we'd post services that are not green to fedora-devel-announce and if we didn't get its levels to rise in X amount of time, we'd be free to enact our contingency plans if we chose.
-Toshio
On 02/25/2011 08:08 AM, Karsten Wade wrote:
I read the results of the L10n meeting as:
Infra: "We really hate to do this, but we have no choice and no time to do anything other than move all L10n services to Tx.net immediately. Sorry about the late notice."
L10n: "Wow, that is really surprising, I don't know if I support this all the way and want some protection in place. I see it's too late to do anything else for the F15 cycle so I'll support the move with the agreement that we revisit this discussion as many of us would prefer to have L10n services hosted by the Fedora Project if we can."
From what I read in that log, the lateness in the F15 cycle meant a program mangement and project leadership decision had to be made, which was really to support what Infrastructure had already decided made the most sense. Bringing it all-of-a-sudden to L10n with a mysteriously-valuable vote in the wings seemed to add to the confusion.
+1 Excellent summary!
So I'm still not following where options were weighed up in open consultation with the community. I agree with your reading of the logs that suggests:
* a firm decision taken by some members of the infra team (who? when? what other options were considered?)
* a firm decision taken by project leadership to support the previous decision (who? when? what other options were considered?)
long before this meeting.
I guess I therefore perceive a serious disjoin between:
* the scenario described above
* the depiction of the move as having been developed in broad consultation or being in any way democratic
If the move was acutally the result of a purely authoritarian, unilaterial "fiat", why not say so? Sometimes decisions like that are indeed necessary in any community, which is why we have leadership -- to make tough and sometimes even unpalatable decisions. But if that was indeed the case (and I'm still open to the idea that I'm badly misreading the situation) -- Why the pretense that it was anything other?
I can easily quantify the disjunction by pointing to specific statements by people in the meeting and in various mailing lists, but I'm not going to single people out this way. I feel bad enough saying *any* of this out loud, because I in no way want to undermine or obstruct our leadership. But nor do I feel like I can just shut up and pretend I'm not seeing what I'm seeing :(
<big snippage -- I really appreciate the analysis and completely endorse your reading of the events, with one exception: >
- Commitment of L10n leadership toward any particular plan. People came in to that meeting with different opinions and agendas, but seemed to come to consensus by the end.
I am not comfortable agreeing with you that consensus existed, when the most obvious gauge of that consensus was a vote:
* that was not advertised as part of the meeting agenda[1] * took place an hour and a half into the meeting * the purpose of which was changing right up to the time the vote was taken * in an environment where dissent had been shot immediately * in an environment where people could tell voters that resistance was futile and those people were not sanctioned * where participants who checked in at the start of the meeting were silent -- under the circumstances, I wouldn't want to claim that their silence was assent * in a multi-cultural environment where standing up and saying "no" in public defiance of authority might be really, really difficult for some people.
In short, nothing about the meeting in general and the vote at 96 minutes in particular makes me feel like it was a safe and supportive environment in which people could express their own opinions freely. I'm a loudmouth, and I'm not sure that *I* would have felt comfortable doing so :(
Community supported infrastructure doesn't have to be of a lesser service level overall, but things tend to be less formal across the board about change impact on community participants.
One lesson to pull from this situation is for *every* service provider (which inclues L10n, Docs, Infrastructure, et al) to have a change management process in place that:
- Exposes problems (needs for change) early and often.
- Encourages discussion and work so decisions (why, how) are visible to all affected.
- Makes sure affected teams are not surprised by developments.
I have seen the Fedora Program Manager and various teams work this process manually over the years, but I'm not sure how many teams have a change management process in place so they can reduce surprise with other Fedora teams?
+1 to all this -- excellent stuff.
Cheers Rudi
[1] http://lists.fedoraproject.org/pipermail/trans/2011-February/008596.html
On 02/24/2011 04:58 PM, Ruediger Landmann wrote:
If the move was acutally the result of a purely authoritarian, unilaterial "fiat", why not say so? Sometimes decisions like that are indeed necessary in any community, which is why we have leadership -- to make tough and sometimes even unpalatable decisions. But if that was indeed the case (and I'm still open to the idea that I'm badly misreading the situation) -- Why the pretense that it was anything other?
I think you are misreading the situation. The Infrastructure team had known for a while that there were problems with the Fedora-local instance of Transifex, and members of the Fedora translator community were complaining about lack of needed functionality.
It was proposed that since the current local transifex instance was not a viable solution for providing translations for Fedora 15, that we consider a move to the hosted tx.net offering (this was also the recommendation from the transifex upstream, who offered to provide this to us at no financial cost).
This solution was presented to the Fedora translation community for consideration (albeit, with not a whole lot of time to decide), and they decided that was a good plan for F15, with the understanding that we can (and probably will) revisit this after Fedora 15 is done.
Can we please put this sort of "pre-made decision" or "decision by fiat" stuff to rest now? There is no attempt to cover anything up, just Fedora Infrastructure trying to identify and deploy a solution that would enable Fedora's translators to complete their work for Fedora 15.
~tom
== Fedora Project
So I'm still not following where options were weighed up in open consultation with the community. I agree with your reading of the logs that suggests:
- a firm decision taken by some members of the infra team (who? when?
what other options were considered?)
- a firm decision taken by project leadership to support the previous
decision (who? when? what other options were considered?)
long before this meeting.
I guess I therefore perceive a serious disjoin between:
the scenario described above
the depiction of the move as having been developed in broad
consultation or being in any way democratic
So, as one of the guys who often lurks in #fedora-admin I know that this has been a problem for some time. Numerous calls for 'someone to maintain t.fp.o' have gone out, and a few different people volunteered in at least the past 6 or so months. Most of the complaints I have seen in the way of tickets about the existing t.fp.o instance came from within l10n, as one would expect. Sadly, the state of that infrastructure hasn't changed much in months.
So this problem has existed for some time, calls for help have essentially gone unanswered (whether there was a wide enough audience is a different matter, and I don't know the answer to that, but it's also hard to essentially call out and offer up root access on boxes that are important to fedora if you don't know the people in advance).
And unlike a democracy, Fedora's decisions (excepting legal issues and the like) are made by the people who are doing the work, and the work of maintaining fedora's infrastructure is done by infra, and thus they made the decision that something had to change, and that discussion started at FUDcon (actually long before, but really concrete steps started appearing post-fudcon.)
I think you've taken the right steps to remediate the situation - eg, identified it's something you care about, and are willing to spend time on, and committed to doing so. Every successful infrastructure project I have seen has needed a long term person like that - whether it was Ian and the wiki, or Jesse (and now dgilmore) with the buildsystems. Every infrastructure project that hasn't had at least one committed person has languished (and now appears on the chopping block). It's not really different than package maintainers orphaning packages (and as a point of reference that notice only goes out to people on -devel)
On Sun, Feb 20, 2011 at 10:33 PM, Ruediger Landmann r.landmann@redhat.com wrote:
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
Does this seem acceptable?
Just as a quick follow-up, I discussed this with the Fedora Board in our board meeting today, and we agreed that the best time to revisit the decision to migrate to transifex.net is after the F15 release. We don't want to run the risk of further shortening the time remaining for translations.
(Futher discussion on the logistics list, I promise!)
-- Jared Smith Fedora Project Leader
On Mon, 2011-02-21 at 15:26 -0500, Jared K. Smith wrote:
[clip]
Just as a quick follow-up, I discussed this with the Fedora Board in our board meeting today, and we agreed that the best time to revisit the decision to migrate to transifex.net is after the F15 release. We don't want to run the risk of further shortening the time remaining for translations.
Just a heads-up ....
This change came up quickly, and perhaps more significantly, with no test instance or testing time. Ideally we should have had testing time, and conversion tasks should have been built into the schedule.
During translation, nightly builds are made of the release notes for the translators. Although, IN PRINCIPLE, it should be a simple change to do it with the new Tx, these things rarely turn out to be as simple as they sound.
There is a risk that the translators will not have test copies as quickly as they expect, and may need to do the builds manually for a while. I haven't completely immersed myself in this process but I understand they might not have the capability of doing those builds manually, so there is a chance they might have to fly blind for a while.
Note that we might be OK. Perhaps everything will go smoothly, but we won't know until mid-March or later.
But I haven't seen mention of this, and admittedly, haven't been paying close attention either. Better to be advised of the risk.
-McD
On 2011-02-21 03:49:23 PM, John J. McDonough wrote:
This change came up quickly, and perhaps more significantly, with no test instance or testing time. Ideally we should have had testing time, and conversion tasks should have been built into the schedule.
For what it's worth, the reason that we went with such a tight timeline for this was that our instance is horribly broken *now*, so moving can only really be an improvement. The fact that so many pepole are OK with letting this cut into the string freeze hopefully gives an idea of exactly how broken the current instance is.
Thanks, Ricky
On Mon, Feb 21, 2011 at 3:26 PM, Jared K. Smith jsmith@fedoraproject.org wrote:
Just as a quick follow-up, I discussed this with the Fedora Board in our board meeting today, and we agreed that the best time to revisit the decision to migrate to transifex.net is after the F15 release. We don't want to run the risk of further shortening the time remaining for translations.
Ugh, I typed this email too quickly and obviously messed up. That should have read "migrate *from* transifex.net", not "migrate to transifex.net". In short, we're still moving to transifex.net now, and will re-evaluate things after the F15 release. I apologize for any confusion I caused.
-- Jared Smith Fedora Project Leader
-
Cheng-Chia Tseng -
David Nalley -
Dimitris Glezos -
Eric Christensen -
Jared K. Smith -
John J. McDonough -
Karsten Wade -
Kévin Raymond -
Luc de Louw -
Noriko Mizumoto -
Oron Peled -
Paul W. Frields -
Ricky Zhou -
Ruediger Landmann -
Runa Bhattacharjee -
Stephen John Smoogen -
Tom Callaway -
Toshio Kuratomi -
Zach Oglesby