Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design User Contribution System #88

Open
JeffThorslund opened this issue Dec 28, 2020 · 0 comments
Open

Design User Contribution System #88

JeffThorslund opened this issue Dec 28, 2020 · 0 comments
Assignees

Comments

@JeffThorslund
Copy link
Owner

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...

  • 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).

  1. A river is a continuous stretch of moving water. It contains 1 or more sections.. For example, the Chilliwack River.
  2. 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.
  3. A rapid is a distinct set of 1 or more features. For example the Classic section has a rapid called "Cocaine".
  4. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants