You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All users should be able to contribute information to Bent Shaft Maps, but there are several reasons why this cannot be a "free for all". When the database begins to scale, project moderators cannot manually filter/review/prune data. The "quality control" has to come from the users and scale as the system grows.
Here are some potential problems...
A user deletes important data.
A user intentionally uploads incorrect data.
A user accidentally uploads incorrect data.
2 users are working on the same project concurrently, how can both of them upload information at the same time? This would similar to a git merge conflict.
A user uploads data that another user does not agree with.
Here are some tools you have to design a contribution workflow.
A combination of these will work best.
Inspiration from git
User roles. For example, the person who created the river could assign permissions to certain people to make changes/allow/review changes.
Voting systems. For example, if data is "good" a user can "upvote" it. Automated deletion of the lowest quality data happens monthly.
User permissions. For example. Users can only delete other peoples data after they have submitted x amount of their own.
TIP: Checkout client/src/mockRivers.js to see a small subset of the datastructure (this is used in development, instead of constantly pulling from the database)
The following is how the data is structured...
The database is composed of river data (a collection of rivers) and user data (a collection of users).
A river is a continuous stretch of moving water. It contains 1 or more sections.. For example, the Chilliwack River.
A section is a stretch of river that is paddled in one outing. It contains 1 or more rapids. For example, the Chilliwack River has a section called the Classic and a section called the Canyon.
A rapid is a distinct set of 1 or more features. For example the Classic section has a rapid called "Cocaine".
A feature is the smallest subsection of data. It could be a line (a path to safely navigate the rapid), an eddy (a calm pool of water within the rapid), a hydraulic (a wave, waterfall, hole, curler, or any distinct obstacle made of water), other features will be added later.
A user has the following attributes:
name
email
Thats it! Add any others that would serve a purpose in your design.
Deliverable
A two stage approach to user contributions
Stage 1:
A light system that only involves protocols that allow user contribution without anything catastrophic happening (Users cant delete entire database, users can submit data). This will be the initial implementation.
Stage 2:
A complete system that allows for seamless user contribution that could involve things like tiered user permission structure, review structure, voting for quality assurance, etc. This will be kept in mind during development, and fully implemented once there is enough incoming data for it to be necessary.
The text was updated successfully, but these errors were encountered:
Summary
All users should be able to contribute information to Bent Shaft Maps, but there are several reasons why this cannot be a "free for all". When the database begins to scale, project moderators cannot manually filter/review/prune data. The "quality control" has to come from the users and scale as the system grows.
Here are some potential problems...
Here are some tools you have to design a contribution workflow.
A combination of these will work best.
git
TIP: Checkout
client/src/mockRivers.js
to see a small subset of the datastructure (this is used in development, instead of constantly pulling from the database)The following is how the data is structured...
The database is composed of river data (a collection of rivers) and user data (a collection of users).
A user has the following attributes:
Thats it! Add any others that would serve a purpose in your design.
Deliverable
A two stage approach to user contributions
Stage 1:
A light system that only involves protocols that allow user contribution without anything catastrophic happening (Users cant delete entire database, users can submit data). This will be the initial implementation.
Stage 2:
A complete system that allows for seamless user contribution that could involve things like tiered user permission structure, review structure, voting for quality assurance, etc. This will be kept in mind during development, and fully implemented once there is enough incoming data for it to be necessary.
The text was updated successfully, but these errors were encountered: