Concerns surrounding translation work

[Jake-Gillberg]

Let me start by saying that I am very happy about the excitement surrounding translation. It's great for a few reasons:

1. it supports the message that "RChain is GLOBAL"
2. it's an easy way to have a diverse set of people get involved

Concerns:

1. Things that don't make sense to translate are being translated (for example, the rosette documentation that is pretty internal to the workings of RChain, and may not even be a part of the stack long term)
2. There is no strategy surrounding which documents are translated. The way we are going about translations doesn't breed the thought of "what things are important to have translated?" or "If a user is looking for RChain documents in language X, what will they find?"
3. It is hard to evaluate the work done on translations
4. Translation issues bringing illegitimacy to the bounty program and driving people away from it
5. Translation work being dominated by a small number of individuals per language, reducing the benefits of drawing more people into this relatively easy entry point to the bounty program.

Personally, I don't feel like I have the time to dig through and understand which translation issues are important, worthwhile, or work well done, so I feel uncomfortable participating in the budgeting process that would make my discomforts heard on these issues.

Solutions that I think could help:

• If I could delegate my vote to someone who I trusted to keep the concerns proposed above in mind, I totally would.
• Have a report on the budget that is being spent out of the bounty program, where breakdowns are rationalized and justified
• Put some sort of limit or cap on translation issues
• Have someone claim responsibility for translation issues and have their own mini funded "translation bounty" program

Here are a few numbers:

• As of writing this issue there are 50 open translation issues, 28% of all open issues
• @lapin7, @dckc could you help me find how much money went to translation issues last month, as a number and percentage of total rewards? And how much is projected for this month?

[dckc]

Thanks for sharing your concerns. In some sense, this looks like the resolution to #302 is inadequate and hence it should be reopened.

Have someone claim responsibility for translation issues ...

@ICA3DaR5 has taken on a "guiding" role (cf. #401) ...

and have their own mini funded "translation bounty" program

but it doesn't go that far.

[deannald]

Issue 4 above. YES. This issue (483) needs to be corralled sooner rather than later if you want to preserve any sense of legitimacy.

[Jake-Gillberg]

@deannaduke Thanks for the support, I added that one (and was driven to finally write this issue) after I heard some of those sentiments expressed by a few people. Could you clarify what, exactly, you see as the cause of degradation of legitimacy? The amount of money spent on these issues? The quality or organization of the output? Also, do any of the solutions proposed above resonate with you? Do you have other ideas?

[deannald]

Well, as a developer looking to contribute to the project, when you go into GitHub bounties, it's a long list of seemingly unvetted requests for services with large price tags. This is a turn-off because it has the feel that no one is minding the store and there's some huge scam going on. I think a lot of people don't want to contribute because they don't want to be associated with potential scam work. And nobody likes the possible mismanagement of funds. It just feels dirty and the whole cryptocurrency space doesn't need any more negatives thrown on it.

It would go a long way if there was a better method of managing what requests are approved (before they even show up), based on actual need and value of the work suggested. As much as I love translations into other languages and some of the other issues submitted, what's the value/future benefit of that work for each language and topic translated? Is it worth the amount being spent on it?

As far as I can tell, not a whole lot of analysis is being done on the issues submitted. It gives people the impression that we're getting fleeced and are totally unsophisticated at requesting bounty work. I would suggest having one or more point people responsible for vetting all requests coming in, approving them to be worked on, and valuing them. The whole "find 2 friends" to approve completed work is too easy to corrupt, so having a body of people to approve the finished work would reduce that problem as well. Identifying the top 3 - 5 languages we want translation services done for and the kind of content we want translated (in other words, guidelines for translation) would also help eliminate a lot of the submissions.

I'm just spitballing at this point, but more organization and guidance is definitely needed.

[lapin7]

@deannaduke and @Jake-Gillberg thanks for your observations.

March will be better. The spreadsheet solution served well as a prototype, but it has clearly come to a drastic end. The new system will be much better, see https://rewards.rchain.coop/ .
The goal is not to have bodies of people that approve issues. I want to give to everybody the possibility of giving a carrot or using a stick. So there have to be at least 3 persons to support an issue and to claim a budget. But all the others can increase or decrease the budgets cq. rewards. This power must be effective, because people just add numbers and percentages, instead of discussions as raising concerns. If needed, then people can explain why they increased or decreased a budget for an issue. So @Jake-Gillberg could give a 0 budget to issues that he's not comfortable with or even give a negative budget. He also could invite other people to vote down certain issues.
Until now we're in a learning process and we allow for some bounties that are not allocated appropriately.
Also the description of issues is more going towards SMART descriptions and not merely brain dumps. People have to recognize that when they formulate an issue in a poor way, that it means for readers a lot of work to understand what the issue is about.

[ResonanceXX]

The web application site looks very dependable.
And this is a welcome solution to the various issues we have had using spread sheets.

Looking forward to its effective use, hope its a better alternative.

Another step forward in the right direction. Cheers!

[dckc]

@deannaduke

It would go a long way if there was a better method of managing what requests are approved (before they even show up),

catch-22, no? How does anybody manage requests before they show up anywhere?

[Barkov-F]

I agree that translation and localization work is now in disorder. Maybe we should make road-maps for our marketing and localization efforts in relevant languages?

First, I think the community has to decide on the list of the canonical texts, videos and docs that are vital for understanding what RChain project is all about. The documents on than list (I think it has to be short, 10 items or less) will have a priority in translation into new languages. Think of it like starter-packs for the potential developers and other contributors, who are not native English speakers. Then we can assign the fixed bounties for that pack translation and subsequent review by a native speaker.

Also, I think that the coop should localize developers.coop site and keep local languages versions up-to-date. Based on the site analytics #454, Chinese, Russian, and English settings visitors add up to almost 80% of total guests, the next 10 locales stand for less than 10%, so I think we should do that three languages first and latter add other languages over certain threshold (like 1% of visitors) if the coop has both human and financial resources to do that.

Translation work, in my view, has to be more aligned with marketing activities, like preparing the multi-language releases about milestones in platform development or multi-language subtitled promotional interviews. Maybe there will be a need to tweak marketing messages for different audiences.

[Ojimadu]

I actually don't like the idea of translating any document one can find. Some of these translations might translate documents that are out of date or redundant. While the multiple translation work going on is good in a way, there is a need to define:

• What languages are needed for the translation (I suggest we start with the top 3 spoken languages save for English)
• What documents needs to be translated. I would prefer seeing tutorial documents like Contributing.MD, FAQs, whitepaper and maybe, some getting started tutorials and interviews as approved by an authority (Board member? Marketing Work group? etc.) being translated rather than any document.

However if a translator is convinced and can proof that there is an active audience (communities, groups, meet ups etc.) for any language or document, then they should give it a try.

[dckc]

Conventionally it's best not to evaluate suggestions until a round of brainstorming is mostly done, but I have developed a muscle that twitches when I hear / see "we should" rather than "I volunteer to ..." or "Fred, would you please ..." and I'm not sure I'll remember later, so...

Transparency and Issue list maintenance by guides

I would suggest having one or more point people responsible for vetting all requests coming in, approving them to be worked on, and valuing them.

Some of us are doing that in #401. You're more than welcome to participate or help find others to share the load.

It is hard to evaluate the work done on translations

I very much share this concern (see my Feb 12 comment in #302 ).

The best approach I have found is issue guides; @ICA3DaR5 has stepped up, but he has only so much bandwidth. Is anyone in a position to help him?

... So @Jake-Gillberg could give a 0 budget to issues that he's not comfortable with ...

I don't think putting the burden on people in his position (which is also my position) can work. By and large, people follow the path of least resistance. It's easier to just not bother than to get into a confrontation. And Jake's (and my) expertise is not in translation, so there's no inherent legitimacy to any criticism he (or I) might give.

Delegation

If I could delegate my vote to someone who I trusted to keep the concerns proposed above in mind, I totally would.

Yes, the loose access control in the spreadsheet system allowed that; so to a certain extent, the web app is a regression in this area. I opened #484 to look into that.

The coalition-of-three risk

The whole "find 2 friends" to approve completed work is too easy to corrupt, so having a body of people to approve the finished work would reduce that problem as well.

The best two approaches I have thought of are

• a trust metric to give some votes more weights when averaging Trust metric to recognize authority in bounty program #375
• slashing conditions so that any bad behavior puts all of a person's reward at risk slashing conditions in the RAM budgeting and Reward system? #261

Which documents to translate?

First, I think the community has to decide on the list of the canonical texts, videos and docs ...

Any suggestions on how we would do that?

Our approach so far (in ISSUE_TEMPLATE.md) is to

1. defer to those who chose the https://github.com/rchain/reference documents and
2. ask that translators justify any work on other documents.

I suppose any one of us could make a pull request to edit ISSUE_TEMPLATE.md to replace the pointer to /reference with a specific list of documents. But curating them separately seems unwise, to me...

... for example, the rosette documentation that is pretty internal to the workings of RChain ...

I found it pretty useful; but I might have found it even if it were in a more obscure place... If it's not important documentation for the community, then it shouldn't be in https://github.com/rchain/reference , should it? Perhaps raise an issue or make a pull request there?

Bounty effort is not fungible

I think we should do that three languages first and latter add other languages over certain threshold (like 1% of visitors) if the coop has both human and financial resources to do that.

If someone shows up with skill and interest in Italian translation, it does little good to say "you really should do Chinese; the audience is much bigger."

This is not a zero-sum game; effort spent on Italian translation doesn't take away from effort spent on Chinese translation. It can make the work on Chinese translation a little harder to coordinate; that's why I invested in a label for China-related issues.

What we can do is say "we'll reward Chinese translation more because the audience is bigger." Each of us has the right, duty, and obligation to do so. But delegating to guides sure would be nice. Again... any volunteers, please?

developer.rchain.coop is contracted to Pyrofex

I think that the coop should localize https://developer.rchain.coop/ site and keep local languages versions up-to-date.

The coop contracted maintenance of that site to pyrofex. Please contact @MParlikar (cf. #184). Oh... I suppose there's a counter-party within the coop who did the contracting. I don't know who that is, though. @kennyrowe would know, I suppose.

[ghost]

My instructions so far have been to leave the translators free on translating the reference contents. Including the Rosette PDF.

My personal opinion on this, is that all the important documents should be translated in order to achieve global scale.

[Keaycee]

@Jake-Gillberg and @deannaduke Thank you for your observation.

I agree with @deannaduke that there are a lot of scam going on without minding the store. I think there should be a bounty limit a coop member can attain. This is because some member take advantage of the decentralized system by creating issues that has no prospect or probably just to gain more budget. Some members be like "Creating 10 to 16 or more issues in a month" Indirectly taking advantage of the system and also having more budget to them self. For example, A coop member having above $15,000 as a reward in a month is very awful. Money spent should be equal to the value of work done. There is a need to to have a bounty limit per individual, as it may help to cub down the fraud intent of members.

[Jake-Gillberg]

@Keaycee The number of issues opened by a contributor or the amount they receive in a month shouldn't be a problem if all work was being reimbursed fairly. More money spent in a month should equal more value created. Your argument for caps relies on the assumption that the bounty program isn't spending money to create value.

[Jake-Gillberg]

What we can do is say "we'll reward Chinese translation more because the audience is bigger."

@ICA3DaR5 What are the standard rules-of-thumb for reimbursement for translation issues? Is it a uniform $/word for all documents? Or do we have a budgeting preference towards a subset of languages? Also, are video subtitles and written documents reimbursed similarly? I would imagine that a translated written document is worth more than translated subtitles.

[Jake-Gillberg]

Also @ICA3DaR5, can you answer the question posed above as to how much money (raw, and as a percentage of total dollars coming out of the bounty program) was spent on translation last month, and how much may be on the deck for this month?

[dckc]

@Jake-Gillberg I can give you a design for computing those dollar amounts:

• use the github graphql API to select the issues with label translation
• grab the monster spreadsheet and use pandas to normalize it (see dbr_norm1.py
• compute the desired result straightfowardly with pandas

I think it would take me between 0.5 and 2 hours. But I'm inclined to spend the time on the trust metric...

[Jake-Gillberg]

@dckc, Awesome, thanks. Yeah, please spend that time on the trust metric :)

[Jake-Gillberg]

Got a number of $30,628.66 for Feb. 2018 across 24 translation issues.

[dckc]

Is it a uniform $/word for all documents?

I recall something about an international guideline along these lines that has been used around here... @kitblake maybe you have details?

[dckc]

@ICA3DaR5 in today's RAM meeting (#469) @9rb expressed a willingness to help guide translation issues; I took the ball to follow up with him. Also, the idea of a specific statement of work to fund management of translations got considerable support.

@9rb are you familiar with putting together SOWs? Perhaps you could share what you know on that topic with @ICA3DaR5 ?

[dckc]

@truffard writes in #711:

@lapin7 said specifically that one must be a native speaker in order to take part in a translation issue.

Did he? In what context? Always cite your sources. Because I'm not aware that @lapin7 has any executive authority over what participants may or may not choose for their tasks. He may value some things less than others, but each of us has that authority, to the extent granted by our peers by the trust metric (#375).

@dckc why is it that we have to remind the same rules over and over again?

Well, because not everyone is born knowing these things, right? Discussing our values repeatedly is what establishes them as our values. We can get the computer to remind people of things we think are important by putting them in ISSUE_TEMPLATE. Note @ICA3DaR5's exhortation to "Please fill the For Translators section." That's the role of a guide. Implicitly, he's saying "The community is not likely to support a budget for this task until you fill it out in such a way that it makes clear the value of the task to RChain."

The guidance there is not that one must be a native speaker, but that "at least two of them have high proficiency" along with some evidence / reputation to back their claims.

If you look at the annotated view of ISSUE_TEMPLATE, you'll see that guidance dates back to Feb 21, based on my Feb 21 checklist suggestion in #302. (I also approved the the relevant PR, #398). (@ICA3DaR5 in the future, if you put more of this "paper trail" in the commit message, everyone can see it from the blame view.) This checklist enjoys a sort of "wiki-consensus"; that is: since any one of us could have changed it, and none of us did, we call consent to it.

Anyone who thinks being a native speaker should be a requirement should submit a pull request to change ISSUE_TEMPLATE.

[dckc]

@allancto would you please propose an edit to ISSUE_TEMPLATE.md regarding your suggestion of value added translation?

Perhaps reduce the screen-space dedicated to the check-list in favor of a link to that google doc I saw somewhere?

cc @deannald

[dckc]

@ICA3DaR5 @michaelizer @zero-andreou would you please conctact @PatrickM727 , @kitblake , and / or @pmoorman about getting them to certify you in the trust metric to reflect that Marketing delegates Translation guiding?

[ghost]

@dckc I am on it!

[dckc]

@AyAyRon-P thanks for stepping up to guide Translation. Note that @allancto did respond to my Jun 30 request with PR #826. I closed that pull request not because the gist of that pull request is no good but because it doesn't follow version control best practices. Please follow up with @allancto on the boundary between Translation and Community Building.

[dckc]

See also discussion of valuation in #841

[dckc]

@allancto 's efforts are elsewhere.

For an example of current thinking in translation, see #936 (comment) .

[dckc]

Concerns around the bounty system (especially Translation) re-surfaced, after RCon3, resulting in a reboot of the bounty system. For details, see: #783 (comment)