Thanks for all the great recommendations so far. We will be sure to take note and discuss it with the TRON DAO team on how we can improve subsequent hackathons!
A short answer for vote buying/vote exchange, it is not allowed and the hackathon admin team will state it again clearly during the hackathon voting period. Ultimately, we want to have a project that is useful and liked by the community, not a project that can make most friends and have them vote for them. There will be a series of vote authenticity checks during and after the poll to ensure that votes are from legit users.
Now, since “projects with repeated entries” were brought up here, let’s discuss this topic in-depth.
Q. For S4, how should we deal with projects that have entered a past TRON hackathon? How do we define an extension of an existing project (e.g. If a project participated in an existing NFT track in S3 and they utilized the NFT and created a game in S4, does it count as a new or existing project)? It’s hard to draw boundaries so let’s see what you all can come up with!
Q. For those who are not following our HackaTRON S3 closely, we actually do have a mini-hackathon that was done on-site (offline) in the U.S. Let’s say for S4, teams that met certain qualifications will have to present to judges on-site, will this make the hackathon more exciting and legit? Please share your thoughts on having on-site hackathon events as part of our ongoing online hackathon.
I believe that if a team initially created an NFT, they can then create new use case compatible with that old NFT, for example: Game, in order to avoid dumping to zero.
This project must be viewed as an old project with a new use case to support the old NFT project. This shouldn’t be considered a brand-new endeavour.
If a project creates an nft collection and, few months later, enters the hackathon again with a game that isn’t related to those nft’s, the game will be judged as a brand new product. Why would it be different if the team decides that the existing nft’s could be used in-game?
For the nft track, the product being judged is the nft collection as what it is during the voting period, not the fact that it’s potentially going to be used in a game in the future. We can only judge what has been delivered, and not some plans for the future. Otherwise projects can start to over promise and get rewarded for something that doesn’t exist yet and might never exist.
If in the next hackathon that same team presents a game using those nft’s, only the product developed during that hackathon should be considered. The game.
I understand that you consider that in this example the game is kind of an extension of the nft collection. But then you will judge the whole thing at once.
Actually I think the game is totally separated and the nft’s shouldn’t be taken in consideration while judging the game. Since it’s the game that has been developed for the second hackathon. It reduces the chances for that project to win if an other project is presenting a brand new game with a brand new nft collection at once.
I will take an other example. Let’s say I present a swap for a hackathon. Then for the next season I present a staking pool or a new design. Then first the hackathon organisation should ask themselves: is that a major improvement? If they decide that yes it is, then people shouldn’t evaluate the swap. They should evaluate the staking pool only or the design only. And they should ask themselves, is a design or a staking pool enough to win a hackathon that has been organised in order to bring talents to the ecosystem and reward products for their innovation, originality, complexity,…?
This is a matter that is very important but also hard to define clearly. I believe that a “significant update” should be easy to determine. For me that definition means a major new feature of an existing project or a completely new dApp from the same team. In S3 there are some obvious carry-overs from S2, some are just cosmetic changes, other are updates of products that were not even completed after S2, which is even worse.
Following your example, if in S3 a team makes a new NFT ecosystem and in S4 creates a game using the NFT as a part of the game, for me it’s perfectly fine. But if a team proposes an app in S3 and a purely graphic rebranding in S4, I don’t think it qualifies as “significant update”.
For me a significant update is easy to define, it’s something that could be presented as a new product.
I will take @intercroneswap as an example. For the season one they have presented the swap if my memory is good. For the second season they have presented analytic tools that have been integrated to the swap. I think the analytic tools could have be presented by themselves as a product. Not just like a feature. So for me that application was valid.
I don’t know if I explain properly. What I mean is that the feature, to be significant, could be presented “out of context”, not like an improvement but as a brand new product.
Edit: I should have read your comment twice. What I’m saying is pretty similar to it ^^
Thats a wonderful question, i will tackle it from these angles, during judging of projects, are the projects milestones/roadmaps taken into consideration when judging? If all these are factors considered in the judgement then a project extension should not be considered as a new product deemed worthy of another hackathon submission.
Example; if project A submits a product for S1 hackathon say “swap feature” and includes in their milestone that they will add a staking pool later, which might even be under production. Then that staking pool feature if submitted for s2 should be disqualified, because if winners are to be paid based on milestone accomplishment, they would have had to complete this staking pool feature before they would have received their price for season 1.
But if milestones are not considered in the judgement process then the ability of the staking pool to function as expected should be considered as a product on it own without looking at the relationship it has with the swapping feature.
Presenting projects on-site will go along way to help us understand how far the team of various projects are willing to go to accomplish their timelines.
Up till now some projects have not given enough updates as possible, with over 200 projects submitted, if on-site presentation is a requirement after reaching a certain qualification, most projects will be disqualified and help clean the system.
People who also try to make some minor changes to existing products submitted for a previous hackathon will be caught in the process.
Also it will help various projects to bond well with other participants in the forum as they will all meet on-site to share their views and ideas from diverse background and cultures.
The on-site presentation videos can be posted on the forum for all to see how well products well articulated in the explanations. Those of us who cant join on-site can join through zoom or google meet to ask our questions after presentations are done. Thank you
For Q1 : It is a subjective assessment ! I feel the criteria should be ‘does it leads to usecase increment / more adoption’ … then yes they should participate! The underlying criteria should remain that the product is deployed on mainnet before voting starts.
For Q2 : Onsite assessment will be difficult as projects are based out of different continents; but yes an online video assessment is a good idea ! There needs to be a preliminary shortlist as doing it for 200-300 projects will be very time consuming.
Hola, si la temporada 2 cumplió unas grandes expectativas, la temporada 3 se ha presentado muy emocionante, con proyectos de gran nivel.
En la temporada 2 me quedo con Turu Global y con el voto que dí a otro proyecto presentado en continuo desarrollo como es Cukies World.
Ninguno me ha decepcionado, lo que han presentado esta nueva temporada a cumplido con lo esperado.
Hola, es una idea que resulta ventajosa para las dos partes. Los desarrolladores reciben fondos a medida que avanzan en el proyecto y Trondao de esta forma revisa el proyecto en cada etapa, lo que hace, que los proyectos se finalicen.
¿Qué podemos hacer para mejorar HackaTRON S4? Indique los motivos de sus sugerencias.
Promocionar que la comunidad participe activamente. Ya que los diferentes puntos de vista crean buenas ideas y pueden ser inspiración para desarrolladores.
cada vez es más difícil atraer a los desarrolladores para que se unan durante un mercado bajista de criptomonedas. ¿Qué idea innovadora tienes para atraer a más desarrolladores a S4?
No tendría que ser un problema el mercado bajista para los desarrolladores, tendrían que verlo como una oportunidad para lanzar buenos proyectos, ya que una vez se llega a un mercado más estable o alcista, en el cual si se ha presentado algo que verdaderamente es interesante hará que usuarios e inversores esten interesados en el, ya que supone una oportunidad de negocio a posteriori.
Entonces sería una manera de dar a entender a los desarrolladores mediante una publicidad que es un buen momento para crear, que en tiempo de alza su proyecto sale ganando.
Digemart has been launched to mainnet and we fulfilled all possible criterias we could.
Digemart Mainnet Contracts
Payment Contract: TXzEHHcDdhKMiHxbWLELsEteykLKAHk8bR Digemart Contract: TVqtrLQZiVepTMmv8xvNKPgKyRZWySTtkK
We launched and announced it as instructed
And been a complex project we did alot of rushing and this is a project that requires atleast a year to build and we have done alot of updates for this hackathon, we built a brand new UI which is up to Industry standard, we bought domain and server and have deployed to main server, at digemart.com, app.digemart.com, we have deployed to the mainnet, Skillpay is a brand new project we worked on from my team, why is not either been listed for the community votes, what’s really happening
