Future of AniDB: Difference between revisions

Latest revision as of 16:59, 27 April 2009

This page is for general ideas/thoughts about the future of AniDB. How should it evolve, what do we want, what should we prioritize, etc.?

More like Wikipedia?

More openness.

Licensing

AniDB is user-driven, open and free, but what about licensing? Who can claim the rights to content that has been added by thousand of different users? Is it possible to move in the direction of Wikipedia? What are the consequences? Alternatives?

Interface

It should be more clear that AniDB is user-driven.

Edit/add/del links should be more visible and shown even when logged out.
Recent changes.
All users should be able to see pending creqs and be allowed to add messages.

Open Source

All the source should be open in the long run..

Features

Also see Development. Most important ATM is Generic PersonCompany DEV.

Reviews

Our reviews are not considered to be very good (citations needed..). The problem might be that we currently fail to separate the good ones from the bad. Since the reviews are sorted by rating it is important that the rating system work, which it doesn't ATM (at least with few votes). Latest reviews shows the low interest for review rating. How can this be improved?

Suggestions:

Higher visibility of reviews: New reviews have high visibility on the main page already, but the question is how high visibility does the main page have? It might help to improve the anime page too. For example, show parts of one random review, show latest reviews for that anime, Ajax, etc.
Allow titles for reviews and display them in latest reviews and possibly on the anime page. Gives the reviewer the ability to "sell" his/her review.
Reward users that provide constructive feedback. Possibly a new review moderator role / karma.
Hide disapproved reviews from the default review page to lower the visibility of the crap reviews.
Add quick reviews or anime comments to give the less committed the ability to share their thoughts without attempting to write full reviews.
Give the reviewers the ability to customize the style (CSS) of their reviews.

TCP API

The content of AniDB should be open and free for everyone to use. We should therefore also make the TCP API public, or at least parts of it. Instead of worrying about people "stealing" our data, we should rather appreciate the users we have and "give something back" to them. Our strength is not the current content, but the users who contribute with new data every day. And if we were to be considered the most serious source of information related to anime (open and free), we would surely only gain contributors, not lose them. Scrapers would have a "right" way to do it, instead of leeching here and there, now and then, by using the site / MyList export / UDP API.

We could alternatively define a new API.

Suggestions:

Open the API (or parts of it) and remove the requirement to encrypt stored data.
Separate file info from the rest of the data: The file info stands for the biggest chuck of data and is for many not really interesting. By separating we lower the barrier for implementing TCP API clients and open for possible performance gains. (The file part could remain non-public if wanted.)
If performance is a issue we could constrain the open part to only support dumps and not 100% up to date data. Possibly introduce hourly dumps.

Ratings

Review the rating system, open it up, allow alternatives, etc.

Reliability

Will AniDB survive, for how long? Hosting, performance, security, legal issues, etc.

Quality

What's the current state of our content? How can we measure the quality? How to improve?

@@ Line 1: / Line 1: @@
 {{TOCright}}
 This page is for general ideas/thoughts about the future of AniDB. How should it evolve, what do we want, what should we prioritize, etc.?
-==More like wikipedia?==
+==More like Wikipedia?==
 More openness.
 ===Licensing===
-AniDB is user-driven, open and free, but what about licensing? Who can claim the rights to content that has been added by thousand of different users? Is it possible to move in the direction of wikipedia? What are the consequences? Alternatives?
+AniDB is user-driven, open and free, but what about licensing? Who can claim the rights to content that has been added by thousand of different users? Is it possible to move in the direction of Wikipedia? What are the consequences? Alternatives?
 ===Interface===
@@ Line 19: / Line 20: @@
 ==Features==
-Also see [[Development]]. Most important atm is [[Generic PersonCompany DEV]].
+Also see [[Development]]. Most important ATM is [[Generic PersonCompany DEV]].
 ===Reviews===
-Our reviews are not considered to be very good (citations needed..). The problem might be that we currently fail to separate the good ones from the bad. Since the reviews are sorted by rating it is important that the rating system work, which it doesn't atm (at least with few votes). ''Latest reviews'' shows the low interest for review rating. How can this be improved?
+Our reviews are not considered to be very good (citations needed..). The problem might be that we currently fail to separate the good ones from the bad. Since the reviews are sorted by rating it is important that the rating system work, which it doesn't ATM (at least with few votes). ''Latest reviews'' shows the low interest for review rating. How can this be improved?
 Suggestions:
-* Higher visibility of reviews: New reviews have high visiblity on the main page already, but the question is how high visiblity does the main page have? It might help to improve the anime page too. For example, show parts of one random review, show latest reviews for that anime, ajax, etc.
+* Higher visibility of reviews: New reviews have high visibility on the main page already, but the question is how high visibility does the main page have? It might help to improve the anime page too. For example, show parts of one random review, show latest reviews for that anime, Ajax, etc.
 * Allow titles for reviews and display them in ''latest reviews'' and possibly on the anime page. Gives the reviewer the ability to "sell" his/her review.
 * Reward users that provide constructive feedback. Possibly a new ''review moderator'' role / karma.
 * Hide disapproved reviews from the default review page to lower the visibility of the crap reviews.
-* Add ''quick reviews'' or ''anime comments'' to give the less commited the ability to share their thoughts without attempting to write full reviews.
+* Add ''quick reviews'' or ''anime comments'' to give the less committed the ability to share their thoughts without attempting to write full reviews.
-* Give the reviers the ability to customize the style (css) of their reviews.
+* Give the reviewers the ability to customize the style (CSS) of their reviews.
 ===TCP API===
-The content of AniDB should be open and free for everyone to use. We should therefore also make the TCP API public, or at least parts of it. Instead of worrying about people "stealing" our data, we should rather appriciate the users we have and "give something back" to them. Our strength is not the current content, but the users who contribute with new data every day. And if we were to be considered the most serious source of information related to anime (open and free), we would surely only gain contributors, not lose them. Scrapers would have a "right" way to do it, instead of leeching here and there, now and then, by using the site / mylist export / UDP API.
+The content of AniDB should be open and free for everyone to use. We should therefore also make the TCP API public, or at least parts of it. Instead of worrying about people "stealing" our data, we should rather appreciate the users we have and "give something back" to them. Our strength is not the current content, but the users who contribute with new data every day. And if we were to be considered the most serious source of information related to anime (open and free), we would surely only gain contributors, not lose them. Scrapers would have a "right" way to do it, instead of leeching here and there, now and then, by using the site / MyList export / UDP API.
 We could alternatively define a new API.
@@ Line 39: / Line 40: @@
 Suggestions:
 * Open the API (or parts of it) and remove the requirement to encrypt stored data.
-* Separate file info from the rest of the data: The file info stands for the biggest chuck of data and is for many not really interesting. By separating we lower the barrier for implementing tcp api clients and open for possible performance gains. (The file part could remain non-public if wanted.)
+* Separate file info from the rest of the data: The file info stands for the biggest chuck of data and is for many not really interesting. By separating we lower the barrier for implementing TCP API clients and open for possible performance gains. (The file part could remain non-public if wanted.)
 * If performance is a issue we could constrain the open part to only support dumps and not 100% up to date data. Possibly introduce hourly dumps.