Contest Proposal: automation uploading submissions to the Free TON sub-government’s mono-repositories

Contest Proposal: automation uploading submissions to the Free TON sub-government’s mono-repositories [draft]

Proposal document: Contest Proposal: automation uploading submissions to the Free TON sub-government’s mono-repositories - Google Docs

Short description

At the last call, it was suggested to create for each sub-government their mono-repository. A repository must contain all the previous and future contest repositories…

Provide a complex solution that allows participants of contests to publish their works to the sub-government mono-repository.

Contest dates

Voting cycle:

9 days

Motivation

Free Ton holds a lot of contests and gets a lot of open source projects to solve different problems. But one problem still hasn’t been solved. What if somebody removes his work? The community will lose a good solution, tool, or code forever. To prevent this we need a create solution that allows participants to be able to upload their own repository to the sub-government mono-repository.

Task

The task of this contest is to provide a solution that allows participants to be able to upload their own code to the sub-guv mono-repository.

Participants of this contest have to create an easy to use solution. It has to be a cross-platform solution and must not depend on the operating system. Participants of this contest are not limited in their imagination and can solve the problem using scripting, web-programming, whatever…

Requirements

  • Solution MUST be easy to use
  • User should be able to input/select SG name, proposal, and submission numbers
  • Solution MUST provide PR into the monorepo as a result
  • Solution MUST be able to create a new submission and update an existing one(proposals with vesting)
  • API?)

Submission format

Submission must be published to a public github repository to the contest branch which MUST be fixed (no changes should be committed there) after the contest dates are over. Binary files are not allowed to change.

README must have the following documentation:

  • How to upload repository to the sub-government repository
  • How to update sub-government repository

PDF should be attached to the submission with the link to the repository’s contest branch along with the telegram id of the participant so that jury members can access the participant and ask questions.

Reject criteria

Submission is rejected if any of these criteria are present.

  • Documentation described in submission format is not provided
  • Tool/Solution doesn’t work

Evaluation criteria

Considering the following criteria set, the submission score increases:

  • Easiness of installation
  • Time of installation
  • Elegant solution
  • Readable source code
  • Detailed documentation

Jury

  • The juror must have a solid understanding of the described technology to provide a score and feedback. If not, the juror should choose to “Abstain”.

Voting:

  • The juror must have a solid understanding of the described technology to provide a score and feedback. If not, the juror should choose to “Abstain”.
  • Jurors or whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
  • Each juror will vote by rating each submission on a scale of 1 to 10 or can choose to reject it if it does not meet requirements or vote “Abstain” if they feel unqualified to judge.
  • Jurors must provide feedback on submissions or lose their reward.
  • The Jury will reject duplicate, sub-par, incomplete, or inappropriate submissions.
  • The number of days for jury voting is hereby set at 21 day.

Contest Rewards

Rewards

  1. :gem: 50’000
  2. :gem: 40’000
  3. :gem: 30’000

Reward Distribution

  • Winners receive 50% of their rewards when contest results are evaluated.
  • Another 50% will be vested in equal parts over a 6-month period with monthly payouts.
  • To receive all 6 distributions, the solution should be supported for 6 months
    • Major GitHub Issues should be resolved within a reasonable timeframe - 2 weeks maximum.

Jury Rewards:

An amount equal to 10% of the total sum of all total tokens awarded to contest winners will be distributed among jurors who vote and provide feedback. This percentage will be awarded on the following basis:

  • The percentage of tokens awarded to the jury will be distributed based on the number of votes each juror casts. For example, if one juror votes 50 times and another juror votes 5 times, the juror who votes 50 times will get 10 times more tokens than the juror who votes 5 times.
  • Feedback is mandatory to collect any rewards.
  • In this particular contest the contestants have a vesting period for their reward distributions. The jurors do not. Jurors will receive their rewards upon completion of the contest in one lump sum, i.e., no vesting period, and as a part of the cumulative 100% reward figure regardless of the long term outcome.

Org Rewards:

An amount equal to 2% of the total sum of all total tokens awarded to contest winners will be distributed among org members who helped to organize and promote the contest, and organize rewards distribution in proportion to the time spent.

Procedural requirements:

Accessibility. All submissions must be accessible for the jury to open and view, so please double-check your submission. If the submission is inaccessible or does not fit the criteria described, jurors may reject the submission.

Timing. Contestants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.

Contact. Each submission must have an identifiable contact that can be matched with your description. If you have not provided a forum description for discussion, then your application should contain links to your online persona, for example, a Telegram ID (preferred) or other direct contact information that can confirm that the submitted work is yours. In the absence of confirmation by the contestant of the authorship of the submitted work, the submission may be rejected.

Multiple submissions.

  • Each contestant has the right to provide several submissions if they are all different from one another. If they are too similar, or in any way appear to be partially the same work done twice, or if they appear to be one whole body of work divided into parts to create the illusion of several submissions, jurors have the right to reject such submissions.
  • If the contestant wants to make an additional submission to replace a previously published submission, the contestant must inform the jury about this fact and indicate which submission is the one to be judged. In this case, only the indicated work will count. If the contestant fails to indicate which submission to judge, only the first submission that is uploaded by timestamp will count. The Jury will reject all others.

Disclaimer

Anyone can participate, but Free TON cannot distribute tokens to US citizens or US entities.