Wed. Jun 16th, 2021
DeVex #15, Free TON,

At the meetup, we discussed the changes in the SG Free TON Dev Experience declaration, whether to extend the SG, and also found out what the members of the Initial and Experience groups should do and whether a large number of participants is needed.

About the extension of the “Free TON Dev Experience SubGovernance” activity

The low activity of Initial group members was noted. Mitja believes that the reason for this is the lack of contests. He is also sincerely surprised by the fact that the Decentralized Name Service (DeNS) has not been launched yet, although it has a ready specification, and developers and users need it. Both Global and Dev Ex SG can be launched.

Other contests also need to be promoted, however, only after the Rust Cup, which starts around the beginning of March. 

Mitya proposed to create a specification for the joint development of GitLab and Free TON via a contest for tools integrated into GitLab for Free TON decentralizaion. At the initial stage, there should be a solution for managing keys and rights to the repository. 

The proposal must first go to GitLab. “The contest will be really interesting,” — Mitja is sure.

The “Free TON Dev Experience SubGovernance” expired on February 15, 2021, so it was necessary to amend the current regulation and determine its further term. It was decided together that contests will certainly be launched not only for smart contracts, but also in other areas, so SG stays!

Boris Pimonenko assures that there will definitely be no problems with contests: “We’re ready to launch a couple of contests in a flash, especially if someone else joins and brings some other ideas. For example, in all chats guys say about it, that a listing contract is needed, and we will probably do it as part of DGO, but that will take time.”

Boris Ivanovsky, in turn, offered to organize work on the assessment of the jury members to improve their efficiency and even agreed to write the relevant test for this. He also clarified whether funds are paid to developers (contest winners) from the vesting pool. They explained that the funds are not paid out, since the funds are not checked in DePool. Mitja assured that after the integration with GitLab, the DePool vesting check will run automatically. But it is necessary to continue working on the interface with GitLab.

By a majority vote, it was decided to remain the regulation of the document in force for another year without allocating additional funds (not yet spent). But they will be allocated if necessary.

Increasing the activity of the Initial Group!

Due to the low activity of the initial group members, the following options were proposed to improve its work:

  1. send requests to the current members of the group, whether they are ready to continue their activities here, if no response is received within 24 hours – automatically remove them from the list. It is also necessary to invite all SG DevEx members to join this group, and if they agree, they will automatically be included in the list of initial members.
  2. Mitja suggested that decision making in SG should be done via SMV contracts, which (as well as the required DeBots) are ready for use.

The meaning of the proposal: TIP-3 tokens are created and distributed to all (willing to vote) SG participants, both current and new arrivals. With these tokens, you can vote via SMV contracts. Each participant can choose an offer that interests him and give tokens for it.

Option №2 was adopted by a majority vote. Mitja was tasked with creating a proposal for a smart contract that implements this feature.

Test of strength

Boris Ivanovsky proposed to include the following requirement in smart contract contests: so that a jury member can deploy and launch the smart contract offered in the proposal. This will help to objectively evaluate the proposal. Since this process is time-consuming, it can be distributed among the judges to save their resources. According to Boris Ivanovsky: “The marks given only by visual inspection of the code are nothing, and judging in general is just a beautiful fence”.

Mitja supports this idea and believes that contestants should provide DeBot, tests, and make-files. Any judge in the jury can take a DeBot, a contract and check its efficiency. Sergey Tyurin added: “There must be a script to deploy the contract system with one-three buttons. To establish a strict sequence of what, when and where. And it is better to have a script that does all this”.

It was decided, if this is not fulfilled in the application, it is rejected.

Judges get a hash!

Mitya is sure that the jury should be formed from the winners of previous smart contract contests. A person who is not familiar with the development of smart contracts cannot judge. 

Sergei Tyurin suggested assigning a special hash to all judges, with which they will sign transactions during the evaluation. To improve the objective assessment of a smart contract, the judges must place a special hash in it, which will mean that the verification has been passed. 

After the vote, it was decided to conduct an experiment.

January vesting payment

Boris Pimonenko claims that only one team updated the SDK version. The rest of the teams allegedly did not fulfill this vesting condition. It was decided to notify all contest winners whether they have updated the SDK version. Vesting will be paid based on the survey results.