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
