Matthew Miller (mattdm@xxxxxxxxxxxxxxxxx) said: > * Open Floor (mattdm, 17:17:32) > * Translators appear to be moving over to Zanata now (gholms, > 17:19:16) I'll bite. 17:24:08 <mattdm> Dimitris Glezos from Transifex makes a request for the board to define a cost/benefit analysis of the risk of using proprietary software like transifex in support roles 17:24:48 <mattdm> No one has brought that to us formally (the transifex thing, obviously, not beer)... does anyone want to pursue it? 17:25:32 <mattdm> Dimitris' argument basically seems to be that the L10n project should push to use whatever tools get the job done, and it's the board's job to push back if they want to use something that is dangerous or counter to ideals 17:25:37 <inode0> This isn't something the board needs to decide if the translation folks sort it out as they are doing really. 17:25:51 <mattdm> inode0 yes, that seems to be my thought, exactly. To be clear; I'm fine with the board staying out of this if they feel translation has it under control. But I can't help but think that how this change happened was strange. Transifex has been effectively proprietary for almost two years [1]. It was confirmed as such 16 months ago [2], and I recall being in some discussions about it around or after that timeframe, although I don't have a link. So... why was this not an issue for translation until now? Were they merely not aware? If the defining thing that made it not fit-for-purpose was the hosted service not being F/OSS (as seems to be the case), is there some effort that should be taken forth to monitor such things? And if this lack of open-sourceness is a bright-line issue for Fedora-related activities, why draw the line here, and no further? Zanata is, after all, hosted on github. While it would certainly be self-immolating to refuse any random upstream piece of software that may be developed or hosted in ways that are not considered fully 'free', it's not as if Zanata has any development community outside of Fedora's chief sponsor. Or, more closely - Fedora infrastructure uses github as well. Fedora design has had flickr and deviantart groups. We've had Google hangouts at FUDCons. We *shut down* Fedora Talk, rather than expand it. To look at it in terms of our foundations, re: building open source software communities: The community includes current and potential or future contributors. Our outreach begins with our free distribution, and we constantly develop ways to give collaborators additional on-ramps for participation. Do as much of the development work as possible staying close to upstream projects. We promote upstream communities by collaborating on patches, providing the latest upstream versions for our development and testing branches wherever possible, and making sure upstream products work consistently and well in our stable releases. Do we collaborate better by using the services where our upstreams may lie, regardless of the 'freedom level' of their implementation status, or do we collaborate better by forcing them to come into our playground on our terms, such as by tying translations to Fedora accounts and Fedora infrastructure. Now, if we're willing to say that our commitment to open-source software trumps our commitment to how we build and expand communities and collaboration, then yes, Transifex would fall short. But then I'd say github for directly Fedora-associated projects would fall short too. But I'm not sure that's right - if we intend to foster communities and grow collaboration in all areas, we need to go where those communities are. That might mean translating in a wider community at Transifex. That might mean collaborating with other developers on github (or bitbucket, or...). That might mean having development discussions via Hangouts, posting the resulting videos to YouTube. It might mean broadcasting our announcements on Twitter. It might mean advertising events on meetup.com, and presenting at other events hosted there. Again - I don't want to change whatever decisions the translators have made. But I wonder if doing this sudden switch based solely on the year-late discovery of Transifex's status sets some sort of precedent (that we don't follow elsewhere) where we sacrifice our goals of building broader communities in favor of an 'only F/OSS' stance. (As to Dmitris's suggestion of a cost/benefit analysis, I would find it naive to think the Fedora board can cause Fedora to switch to something other than the platform written and maintained by Red Hat i18n engineering and used by RH L10N for other projects; the cost/benefit analysis that would drive such a discussion would not be factoring the cost to non-RH translators in general.) Bill [1] https://github.com/transifex/transifex/issues/206 [2] https://github.com/transifex/transifex/issues/206#issuecomment-15243207 _______________________________________________ board-discuss mailing list board-discuss@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/board-discuss
