eloquence / lib.reviews Goto Github PK

Since we'll probably keep invites enabled for a while, let's make them less hackish

Permission check works, but button is shown when it shouldn't be.

Thesse are becoming kind of messy and unmanageable, let's clean them up.

Using auto-sni and letsencrypt

Good morning / Guten Tag!

Currently reviews can be written in English or in German. What is the plan for supporting more languages?

Right now only creators can delete. Mods should be able to as well.

If we're looking at a single item from a feed, we should still be able to use standard access keys for editing at a minimum.

Easy search completion for things to be reviewed powered by Wikidata would be a nice "bootstrapping" feature. Maybe not for first release if it's too complex.

To consider:

• We don't want to review living people
• We want to exclude stuff like disambiguation pages and other Wikimedia-specific stuff
• We may want to "auto-sync" at least descriptions/labels on a regular basis

We should detect whether we can get a DB connection, and print a more friendly error if we don't -> recover once we have it.

At minimum we'll need to transpile ES6 code for older browsers

This should be sufficient for now to protect against roaming spambots.

Not a huge deal, but since we have the code for it already, let's use it.

Merging is going to be super-important very quickly as people use different URLs to identify the same item. So we should have a basic merge feature from the get-go, initially permission-restricted until we can make it low-risk to perform.

Running a hidden service shouldn't be too hard, and a fun exercise. Since other review sites that shall not be named are completely blocked on Tor, this might be a nice service to the Tor community.

Time to add basic site config file management.

We need to validate submitted URLs server-side, not just client side.

We'll need at least a placeholder logo for a few places (e.g., getting rid of the Twitter egg).

This is must-have before we put the service on the public web.

Too many custom templates. Let's make this smarter.

We need to keep a log of all moderator actions so we can audit them. F-Droid will want to empower members of its community to moderate reviews, so this is a blocker for them. This could be the same as #30.

Blocker for F-Droid community

Permalinkable reviews. We won't have pretty URLs/slugs for these, just IDs.

Since we have a revisioning strategy in place now, we should at least have a basic edit feature for reviews.

This ticket is for finalizing the spec for URL paths & slugs, e.g.:

lib.reviews/some-business-or-thing == standard slug
lib.reviews/user/eloquence == local user name
lib.reviews/user/id/ == user from some external DB where we can't enforce naming conventions

Should language be accounted for in the URL? If we don't, we may at least want to support multiple slugs per item so people can have memorable URLs in their language.

Team creation, team metadata editing, team membership, team-specific permissions. Should be enough to support a universal translators team that has permission to edit all content translations.

Let's do basic form sanity checks as we do on the "new review" page, prior to submission.

We'll want to add freeyourstuff.cc-style authentication with local/Twitter/Facebook/Google accounts, but this time we'll be using RethinkDB and Express-Passport.

Highlight active language, add some style bits.

Basic user page that lists their contributions, maybe some profile info

Consider doing some checks on submitted URLs, such as:

1. the result of any 301 or 302 redirects, and then
2. the representation URL in the document , if any.

This ticket holds reminders for changes we want to make as part of the LTS6 upgrade in October.

• We can remove the harmony-reflect shim
• We can make abstract classes actually abstract by checking new.target
• We may want to use default parameters in a couple of places
• We can use rest parameters and turn that linter option (prefer-rest) back on

Should support

• URLs that describe the thing being reviewed
• Review text
• Star rating

This is data we'll want to surface in a few contexts.

Since we won't have fancy search in alpha1, we should at least have a page-able feed of all reviews ever written (globally and by user).

The current feed query is unwieldy and doesn't support other types of events. We want a feed that shows reviews, new sign-ups, edits, and other activity, with optional filters. So we need to probably fire log events to a central feed table all over the place. Nice to have would be real-time notifications of feed updates.

Some stuff needs to be moved into provider, esp. feed stuff.

Goals

1. Show no error details in production (perhaps unless user has permission to see them)
2. Log all serious errors
3. Make error page reasonably non-ugly

Think about it. This project has everything to do with the Wikimedia family, and full integration with it would be very benefitial to both.

Wikivoyage, if I recall correctly, was adopted by Wikimedia upon request. Maybe that would be a good option for lib.reviews as well.

We should create a custom cheatsheet on help.wtf, and link to it instead of the current one.

Too much text, too little whitespace. Button doesn't collapse nicely on mobile.