Hi, I know David personally from when we used to be colleagues at the NCC, some years ago. I am very happy to see him joining the db-wg and wanting to help. On 11/4/16 4:18 PM, Sander Steffann wrote:
Hi David,
Can you elaborate further on your motivation why you want to volunteer as chair of the DB-WG? What role does the database play in your professional work? Thanks for the questions.
I left the NCC a little over a year ago and I am now going to be working with the RIPE Database again as part of a new job, mainly simple contacts and network registration. When I first started using the RIPE Database, it was an open Database where users could change almost any data and break any policies. It was confusing for the users and generating a lot of work for the RIPE NCC staff.
Many new users were confused as to why they were able to make changes that were not allowed, many experienced users were having "bad script days" and making changes that then required the intervention of the RIPE NCC to fix.
While working for the RIPE NCC I was involved in creating the sets of business rules that prevents the deletion or modification of data considered "maintained" by the RIPE NCC.
That greatly improved the overall data quality and lowered the amount of time spent by the RIPE NCC in restoring information and having to to contact the users and also improved the user experience at the same time.
Many hours were spent in testing new releases to test new functionalities and discovering what would eventually break the expected behavior of the RIPE Database.
I would like to continue with that and help in further enhancing the usability of the RIPE Database, I know how it works and how to not break it fundamentally when implementing changes to its behavior. I am not a coder, my views and use of the RIPE Database is one from a user perspective only, based on the available public tools only.
I like to investigate how to achieve the intended goals of the RIPE Database, registration of networks and contacts while adhering to the RIPE policies, all this in the less cumbersome way possible. That experience should be as painless as possible for all users, basic users and power users alike.
Any changes should always be analysed with pros and cons to see what will break if implemented, and how to then circumvent this and ensure continuity of expected functionalities. Sounds good to me :) +1 for David A big +1 from me as well.
Cheers, Sander
cheers, elvis