Thank you very much for your comments; I really appreciate them very much!
It gives me to understand that all of you actually took time to understand it and who appreciate the importance of this proposal.
1.- Part of why it took me a while to answer is because I have carefully read all the objections, in detail. I took the time to analyze each response and each recommendation.
Unfortunately many of the suggestions do not solve the challenges that this proposal seeks to address.
2.- As a conclusion I have determined that the following worrisome issues do exist:
- What happens if too many reports are presented?
It is an unknown parameter and the fear of receiving let’s say 3,000 reports for a contest is not an unfounded fear.
However: A “RANDOM SELECTION” OF REPORTS exposes us to discard high-quality ones, to simply reduce the number of reports to read.
THAT’S WHY: It makes sense to include a “Leaker” in the proposal with an incentive of 100 SOV per month.
If at the end of the Quarter no more than 30 reports per contest are received, this position will be eliminated.
- These contests are based on a continuous process.
There is a more or less continuous rate of issue reports that is expected to be translated into a continuous rate of user reports.
THAT IS WHY A MONTHLY CONTEST will only make us read twice as many reports as in a bi-weekly contest; In addition, we expose ourselves to receiving reports far from the opportune moment. It is not desirable to receive a report of something that should have been tested 10 days ago. Sovryn is evolving at a very fast pace to expose us to that risk.
WHILE THERE ARE INCENTIVES to produce more reports by offering rewards for them; there is also the extra effort of the user to make a minimally acceptable report.
These are forces that tend to cancel each other out, producing as a result a number of reports not likely higher than the number of incidents that users report to us on a daily basis.
- A challenge posed by this proposal is to take advantage of user experience to anticipate the discovery of bugs in immunefi, which may results in significant savings for Sovryn.
THIS IS WHY GIT COIN does not provide added value:
a. Git Coin cannot offer rewards on SOV token, and they will charge their commission.
b. We already have a payment mechanism with the MultiSigWallet. We don’t need the one from Git Coin.
c. Git Coin requires an additional learning curve and admin functions (more seemingly unnecessary work, for Sovryn).
d. Git Coin is a tool, not an extra helper. (Git Coin doesn’t come with a funny dwarf in a box ready to do our work for us.)
e. Git Coin is ANOTHER platform with ITS own problems, with which we are going to bring our users face to face, instead of receiving them directly through our means; that complicates the picture more, especially for the user.
- It is not intended to create another one bug hunt, but a more complete user feedback; every day there are reports of issues brought by users, which will always be there because they are complaints about malfunctions of the platform, which is under evolving process.
These reports are free, yes, and they are so at the expense of having to chat with the user (which is very time consuming) to find out what is going on. The reports do not replace this, but they are expected to mitigate the situation. Reports can also enrich our Wiki with additional information.
A report saves Sovryn staff chat time. But, in any case, attending the user is a job that we cannot avoid.
3.- I’d love to have the time to respond to all the others concerns that were expressed, especially those of @light , @stefan and @exiledsurfer ; I am very grateful for your suggestions; unfortunately, for the reasons I have just mentioned and others, in my opinion those suggestions would not contribute to a real improvement towards the efficiency of the process already proposed.
4.-I am going to mention the latest modifications of SIP-0013.
(I know that due the number, no one will want to take me away the label … 
)
4.1. It is indicated (I did not do it originally) that the report must be made in English.
4.2. The report must include an Abstract, of no more than 300 words, with the headlines very summarized of what was covered in the report.
4.3. The report must include a conclusion, of no more than 400 words, with highly summarized headlines about what was discovered or recommended in the report.
4.4. A Leaker will be on the work team on a trial basis only for this quarter period. The aim of this “Leaker” is to save work to the jury.
4.5. The main responsibility of the leaker will be to maintain an excel sheet with the list of reported incidents
4.6. The Leaker will also have the responsibility to discard reports that do not meet the minimum required quality.
4.7. The Leaker will discard repeated reports, giving priority to the first to appear.
The Leaker can be any member of our community and will be selected from among those who show interest in carrying out the task, by the members of the jury.
Thanks to everyone for your interest