Ouch! But Spot on, @heigo, I hear you loud and clear.
This is currently our biggest problem. @Patrickayelle hit the nail in the head while saying that we are working to correct that and, in the meanwhile, while trying to hire, we are prioritizing development of things that will make a better product, while letting some balls drop - among them: community support.
Let me offer an explanation of why this happened the way it happened:
- We went from a team of 4 to a team of 3, and hiring is being really difficult. Moreover, hiring in August means that most people have decided to take summer holidays and join the team after.
- We are indeed hiring a specific person for support. He is a fucking superstar that has built support systems from scratch for two tech startups already… I can’t wait for him to join the team! he’s the best person to take care of these concerns BY FAR.
- Regarding the certainty on ETH2.0 packages and tools - everything that has been available on Testnet will be available, except the automatic deployment of validator keys that we prepared for the Onyx testnet (we have decided to go with the Official ETH2.0 Launchpad for generating withdrawal and validator keys, instead of an easier but potentially less secure alternative). The ETH2.0 module for the DMS, the dashboard and the client switching features will be available.
You WILL be able to monitor your hardware and validators, rest assured. The only reason why we haven’t integrated it beyond the dashboard in the Medalla package (meaning no integration in the Dappnode Monitoring System yet) is because we have had to prioritize hardcore - publish updates for beacon and validators being one of them.
I don’t quite understand what you mean by “no claim to updates”. Could you elaborate?
That’s a great point on transparency. Let me clear it here and now, but we can probably have a better update mechanism for the donors. The money, as explained in the gitcoin grant description, is being used for 2 purposes:
- ETH2.0 development. That’s what paid for the DAppNode packages, the development of the validator dashboard, the “switch client” feature, etc. And yes, it could have been faster, and it will be as soon as we get more people.
- The second acknowledges the fact that the core team can’t be the only one championing packages or it will become a bottleneck. Managing the coordination with a potentially unlimited number of open source projects to maintain the packages updated is just not feasible - hence we suggested offering bounties to community members to do so. A more formalized approach to doing it has been the Champions initiative (read more here: Package Champions).
There are some talks with community members to do just that.
Appreciate you taking the time to lay down your concerns so clearly!