As a user I want to have breadcrumbs showing me where I am in the field hierarchy when I'm viewing a field so I can easily navigate around the field hierarchy.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

Fields exist in a hierarchy, essentially forming a multi-linked tree (each field can have multiple parents and N children). When we're viewing a field, we currently list the children and all papers in that field or any of its childen, but we don't list the parents. We want to show a breadcrumb style tree of the parents.

It might look something like this:

[physics] > [quantum-physics] > [quantum-information-theory]

Or this for multiple parents:

[physics] > [biophysics]
[biology] > 

Acceptance Criteria

At what point is this story considered "done"?

• On the /field/:id route which loads the FieldPage allowing us to view the description, children and papers of a single field, we show breadcrumbs for the fields parent tree. The breadcrumbs should show immediately under the field name header and above the description.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to be able to edit my profile (name, institution, location, and bio) so I can update them when they change, and in some cases (location, bio) set them in the first place.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We currently only allow the user to enter name and institution on the registration screen. They need a way to set their location and bio as well, and to update their institution and name should they change.

Acceptance Criteria

At what point is this story considered "done"?

• We have a /user/account route that loads a UserAccountPage which loads a UserAccountView.
• We have an EditUserProfileForm that can be loaded into a pane of the UserAccountView.
• The EditUserProfileForm provides text fields for editing name, institution, and location. It provides a Markdown capable text area for bio.
• BONUS: The textarea provides a markdown capable WYSIWYG editor. This will be a required beta feature, but it's bonus for the alpha.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a [who] I want to [what] so I can [why].

Story Background

Author:

What is the history or background behind this story? What context the developer researching or implementing this story need?

Acceptance Criteria

Author:

At what point is this story considered "done"?

• Users can add any tag they like, they are limited to 10 fields

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

As a paper owner I want to be able to control which authors have which permissions so I can allow some authors to submit new versions, or edit title/authors/fields but prevent others.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

Papers can have a lot of authors, and they shouldn't all have owner permissions (the ability to edit or submit new versions). But in many cases, submitting authors will want to share ownership permissions with one or more of their co-authors so that they don't have to be the only one responding to feedback. We need a way for authors to assign ownership permissions to one or more of their co-authors.

Acceptance Criteria

At what point is this story considered "done"?

• After submitting a paper authors can assign 0..N of their co-authors as owners, granting edit permissions and the ability to upload new versions.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

Describe the bug
The home page should re-render after the user logs out and the session is wiped in order to respect changes in the session. An indication of this would be the WelcomeNotice and SupportNotice reappearing on the home page after being dismissed by a logged in user. They don't right now, which indicates the home page is not noticing and respecting the logout.

To Reproduce

1. Register a user.
2. Login as the registered user.
3. Dismiss the WelcomeNotice and the SupportNotice.
4. Log out

Expected behavior
Expect to see the dismissed WelcomeNotice and SupportNotice reappear on the homepage. They don't reappear until after a refresh.

As a user I want to have work I've already done in the field but not posted on Peer Review represented in my reputation so I can start participating on Peer Review at a level commensurate with my knowledge and experience.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We need a way to give experienced researchers initial reputation. The easiest way to do this is to just treat citations as votes for the purposes of initial reputation. There are a couple of potential places where we can get citation counts for potential researchers - Google Scholar being the most obvious one. We should be able to either scrape a citation count or find an API where we can get it. And then we can apply it to fields either by allowing researchers to divy it up in the way that most makes sense to them, or by scaping tagging information from somewhere.

Either way, we want to allow researchers to initialize their reputation because that will kickstart the community. This won't work with out it.

Acceptance Criteria

At what point is this story considered "done"?

• Researchers can point us to a profile they have on another site (Google Scholar, etc) where we can scrape a citation count for them.
  • We treat each citation as an upvote.
• We have a way to assign the reputation gained from citations to fields. Either the user can do it, or we do it for them through some sort of scraping.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a [who] I want to [what] so I can [why].

Story Background

Author:

What is the history or background behind this story? What context the developer researching or implementing this story need?

Acceptance Criteria

Author:

At what point is this story considered "done"?

• User can add existing users to a paper as authors
• User can invite new users and add them to the paper as authors
• Users can add authors when first posting the paper or at any point during the posting stage

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

As a developer I want to unit test all the things so I can be confident that they are working the way I want them to.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We basically abandoned the unit tests in the race to alpha. Now we need to go back and write unit tests for all the things. This will also provide us with the opportunity to harden the alpha, think through the unhappy paths and edge cases. Then we'll work to maintain the tests as we write the beta features and continue hardening and thinking through edge cases.

Acceptance Criteria

At what point is this story considered "done"?

• We have unit tests for the backend:
  • We have unit tests for each controller (these will also test the DAOs, and services since the controllers mostly wrap them
• We have unit tests for the frontend:
  • We have unit tests for each Redux slice
  • We have unit tests for each React component

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a developer I want to define the initial database structure so I can work from it in developing the initial MVP.

Story Background

Author: @danielBingham

What is the history or background behind this story? What context the developer researching or implementing this story need?

We need an initial, minimum viable database structure that we can use to develop the first base feature set so that we have something to build off of.

Acceptance Criteria

Author: @danielBingham

At what point is this story considered "done"?

• We have decided what tables to define for the alpha.
• We have decided what fields to include on those tables for the alpha.
• We have the table definitions written for the initial tables.

Dependencies

Author: @danielBingham

What stories does this one depend on? What do we need to do first before we can call this one done?

No dependencies.

As a developer I want to have a unified interface for uploading files so I don't have to duplicate code.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

A piece of techdebt we took on while writing the paper submission code was just writing file upload right into the PaperController and storing the file path right on the paper_versions table. But that doesn't make much sense. We'll probably want to upload multiple kinds of files at some point (at a minimum, profile pictures eventually) and the code for uploading files is going to be the same across the board - accept the upload, give it a temp path in a temp directory, move it to its final path in a final home, store the path in the database and then reference it. So we should build a single interface around it, using a FileController and a single files table which stores file paths, types, and gives them an id that can be referenced by other tables.

Acceptance Criteria

At what point is this story considered "done"?

• We have a FileController that exposes a single upload action.
• The upload action accepts a file or files and records their temp path in a files table, along with their type. It returns a file object with id, type, and path.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to be able to update my core account details (email, password) so I can update then when they need to change.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?
We want to provide an account update view on the User Account page (/user/account) that allows the authenticated to change their email and password. This is just the alpha version of this, so we'll require the current password and password confirmation, but we're not going to worry about sending confirmation emails of any kind. Same for the email.

Acceptance Criteria

At what point is this story considered "done"?

• We have a view that can be plugged into the UserAccountView, tentative name UserAccountDetailsForm.
• UserAccountDetailsForm provides fields to edit email and to enter a new password (with confirmation). It also provides a field to enter the current password and requires it to be entered in order to successfully submit.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to gain permissions based on reputation so I can be rewarded for my work.

As a user, I want to receive reviews only from peers with enough reputation in my fields, so I can be sure the right people are reviewing my work.

As a user, I only want my paper voted on by peers with enough reputation in fields, so I can be sure the right people are assessing my work.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

The plan has always been for users to gain permissions as their reputation increased. So far we haven't implemented this in the alpha, because it makes testing a lot easier. But we'll need to implement it before we go to beta. Initially, it's pretty straight forward. Uses will need a certain amount of reputation to post a review to a draft, vote, or submit a response to a published paper. We'll need to decide where the lines are. And we may need to allow there to be different lines for different fields.

Acceptance Criteria

At what point is this story considered "done"?

• Users can only review a paper if they have X reputation in one or more of the tagged fields.
• Users can only vote on a paper if they have Y reputation in one or more of the tagged fields.
• Users can only respond to a paper if they have Z reputation in one or more of the tagged fields.
• We have determined what X,Y, and Z should be.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to maximize the SEO of my profile page so that people can find me and my publications.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?
Currently user profile urls are of the form /user/:id. Ideally, we'd want them to be of the form /user/:id/:name-based-slug, eg. /user/1/james-watson. We don't need the slug for anything on our end, but it's really helpful for SEO. We should generate slugs from the name they enter in their profile.

Acceptance Criteria

At what point is this story considered "done"?

• We generate URL safe slugs from the names people enter, replacing spaces with -.
• We know how to handle other special characters that might appear in their names (remove? encode?)
• User profile links include the slug. Users going to /user/:id are redirected to the profile with the slug.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to copy and paste text from PDFs so I can reference the copied text.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

PDF.js renders the PDF to a canvas. What this means is that the text isn't copyable. PDF.js has a workaround for this that involves overlaying the text on the canvas using transparent divs. The PDFJSViewer does this, but using it in the raw like we are, this feature doesn't come out of the box. However, we can get access to the TextContent and it comes to us in an array of lines with x and y coordinates. So we can implement this feature ourselves.

On the review screen, there's an extra hitch, which is that clicking on the PDF starts a new comment. So we'll need some method to allow the user to choose whether they are commenting or selecting.

Acceptance Criteria

At what point is this story considered "done"?

• Users can select text from any PDF we display.
• On the review screen, user can choose whether they'd like to start a new comment thread or select text when clicking -OR- we have a very intuitive way of determining which they are trying to do for them.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As an author I want to be able to add Authors to my papers who aren't users yet so I can post papers with out having to get all of my co-authors to sign up to peer review before hand.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

It's really common for papers to have multiple co-authors and at first it's going to be really rare that all of those co-authors already have accounts on Peer Review. We need to provide a way for authors to add their co-authors to papers with out those co-authors having already registered. Bonus, we can provide a way for authors to invite their co-authors as they do this. We'll take email and provide an "Invite?" checkbox. We'll use the email to attach those co-authors to their papers if they ever register in the future (whether responding to the invite or registering on their own).

Acceptance Criteria

At what point is this story considered "done"?

• While adding co-authors to a paper, if a user hits "enter" on an author with out a suggestion, we show them a form to enter the author's email in the suggestion area as well as a checkbox asking them to invite the co-author. We can explain that we need the email to attach the co-author to their papers should they register in the future, even the author doesn't want to invite them.
• We should grey out the author input until the user enters an email for the author.
• We should create a new user for the entered email, and use a field to differentiate users that have registered from those that are unregistered co-authors.
• BONUS: Send an invite email to the invited author. (We'll save this for the beta.)

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to filter the UserList by field and/or institution so I can see who is active on the site in certain fields or from certain institutions.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

Users are probably going to want to be able to see who else is on the site in their field or at their institution, so we should give them a way to filter the UserList for that information.

Acceptance Criteria

At what point is this story considered "done"?

• The UserList can be filtered by field. Where users are considered to be in a field if they have any reputation in that field.
• The UserList can be filtered by institution, using a pure text search against the users.institution field.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to view paper PDFs using a viewer that allows me to easily navigate and view a single page at a time so I don't have to scroll way down a multi-page PDF to get to responses/comments/etc.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

Right now we're just rendering all the PDF pages to the screen. This works great for reviews where there could be comments on each page, but that's not ideal for viewing the paper where we want to load additional content after the paper (like responses). We need to build a PDF viewer that shows a single page at a time and exposes navigation controls to the user. The one built into PDF.js doesn't play nice with React, but it should be easy enough to build our own PDFViewer react component using the API PDF.js exposes.

Acceptance Criteria

At what point is this story considered "done"?

• We have a PDFViewer react component we can give a PDF. It shows one page at a time and provides controls for navigation.
  • It provides "next" and "previous" buttons for moving one page at a time.
  • It provides a "page" field for jumping to a page, this also shows what page is being viewed.
  • It lists the total number of pages.
  • When focused, the arrow keys can be used to navigate as well.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to have the option of using a Markdown capable WYSIWIG editor so I can choose whether to write Markdown or just write WYSIWIG rich text.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

Some users will be very comfortable with Markdown. Most will not. We'll need to provide WYSIWIG editors to allow users not comfortable with Markdown to express themselves clearly. The site won't feel polished with out them.

Acceptance Criteria

At what point is this story considered "done"?

• Anywhere we have a textarea we show a WYSIWIG editor. The editor should allow the user to switch between entering Markdown and entering rich text, while serializing the text as Markdown.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a [who] I want to [what] so I can [why].

Story Background

Author:

What is the history or background behind this story? What context the developer researching or implementing this story need?

Acceptance Criteria

Author:

At what point is this story considered "done"?

• Votes on published papers affect all authors reputation
  • Up votes give 20 reputation
  • Down votes take 2 (or 5??) reputation

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

The MySQL drivers for Node really suck. There's a good argument Postgres is a better fit for this project anyway and the only thing stopping me was the idea I'd move faster sticking with what I know. But given the quality of the MySQL drivers, I don't think that's actually true. Let's switch.

As a [who] I want to [what] so I can [why].

Story Background

Author:

What is the history or background behind this story? What context the developer researching or implementing this story need?

Acceptance Criteria

Author:

At what point is this story considered "done"?

• Criteria 1
• Criteria 2

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

As a user I want to be able to edit the title, authors, and fields of a draft paper so I can fully respond to review feedback.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

Authors will probably need to be able to edit all aspects of a paper during review feedback, and that may include the title, authors, or fields associated with it. We need to provide a way for them to do that.

We'll probably need a way to assign author permissions in the near future.

Acceptance Criteria

At what point is this story considered "done"?

• Owners (submitting authors) of a paper can edit the title, authors, and fields of a paper in review.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to be able to create an account and login so I can post papers, post reviews, and comment and have them all associated with my account.

Story Background

Author: Bing

What is the history or background behind this story? What context the developer researching or implementing this story need?

We're going to need a login and user account system so that we can associate academic papers with their authors. At the beginning, this doesn't need to be overly complex. A simple email / password login, the ability to set a name on a profile, and baseline secure practices should do it.

Acceptance Criteria

Author: Bing

At what point is this story considered "done"?

• User can create an account (register) with an email and a password
• User can login with their email and password
• User can update their profile with their name and background
• Passwords are stored securely (salted and hashed)

Dependencies

Author: Bing

What stories does this one depend on? What do we need to do first before we can call this one done?

This story depends on #2 for the initial database structure.

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

As an academic I want to be able to get feedback on my papers so I can improve them before I publish them to the world.

Story Background

Author: Bing

What is the history or background behind this story? What context the developer researching or implementing this story need?

We want other academics with reputation in the fields a paper is tagged with to be able to submit pre-publish feedback to the author of the paper. This will supplant the review and editorial stage of publishing that currently exists where academics submit papers to journals and the journals get other academics to review it and submit feedback. The feedback and editing stage is very important for a lot of academics and very helpful in refining a paper and catching issues pre-publish.

This is separate from reviewing and critiquing a paper once it has been published.

In some cases, this feedback might result in a paper being with drawn from publication and reworked, but in most it will probably just be relatively minor clarifications and corrections. In the future, we'll want to put structures in place (and moderation in place) that encourage only constructive feedback and strongly discourage purely destructive, harsh feedback (unless the paper really deserves it). For now, we just need to create a basic posting for that allows users who aren't authors of the paper to post feedback to a particular version of the paper. The feedback should remain attached to that version and should be hidden when a new version is posted. Users can view the old feedback by viewing the old version.

Acceptance Criteria

Author:

At what point is this story considered "done"?

• A user who isn't an author on a paper can post feedback to the latest version of that paper
• Feedbacks stick to the version of the paper and are only visible when viewing that version

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

As a developer I want to be able to put the alpha version up on a staging server I can point people to so I can collect early alpha feedback.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We need to be able to collect feedback, so we need to be able to show it to people. To do that, we need the beginnings of an infrastructure. A staging server will do for now.

Acceptance Criteria

At what point is this story considered "done"?

• We have a basic infrastructure we can put Peer Review on so that we can collect feedback. This doesn't need to be more than a VM and a managed database, with S3 equivalent for storage.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to see relative dates rather than timestamps so I can easily understand how long ago something was posted.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

Right now we're just showing Postgres' timestamps. We should convert them to relative dates.

Acceptance Criteria

At what point is this story considered "done"?

• We use Relative Dates where ever we show a date.
• It should show:
  • Seconds ago up to 60 seconds.
  • Minutes ago up to 60 minutes.
  • Hours ago up to 24 hours.
  • a Mon Day, Year formatted date after that.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to be able to receive double blind reviews so I can be confident that my review feedback is unbiased.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

There's a debate going in academia as to whether open reviews or double blind reviews are better. There are strong arguments to be made on both sides, and it feels like there isn't a clear answer. So we want to let the authors choose whether they want reviews to be double blind or open. We need to build a double blind review system and then provide a switch on the publish page allowing the author to choose which it is. Then we need to signal to the reviewers somehow which it is.

Acceptance Criteria

At what point is this story considered "done"?

• We provide a switch on the publish page allowing authors to choose between double blind and open reviews.
• Double blind reviews do not reveal any user information, for either the reviewers or the authors, anywhere. That includes in the code (you shouldn't be able to discover who left a review, or comments, or authored the paper by inspecting the review pages anywhere).
  • We won't try to strip author information out of the submitted PDF, we'll leave that as an exercise for the user.
• Double blind reviews allow authors to upload a final version of the PDF before publishing that adds authors back in.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a User I want to have review comments that don't overlap with each other so I can clearly see all the comments I have with out having to guess that a comment might be hidden beneath another comment.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We're currently just using absolute pinning to pin the comment on the same horizontal plane of the document as its pin. This was a convenient way to have comments available quickly, but isn't the best UI ultimately. The biggest problem is that comments overlap, which we definitely do not want. There are a couple of ways we could go about solving this. We could attempt the Google Docs model where comments push each other out of the way to avoid overlapping and selecting a pin moves them around to put the pinned comment in the relevant spot. We could have a scroll pane for each page and simply have selecting a pin scroll the relevant comment to the top of the pane - this is not ideal when the pin is at the bottom of the page. We could have a scroll pane for the whole document, absolutely pin comments to the horizontal plane of their pin, but place overlaps below their pin in the scroll pane to prevent overlap, scrolling the pane to line up the comment with the pin when a pin is clicked. We could explore other possible solutions as well (users can move comments like windows, etc)

Acceptance Criteria

At what point is this story considered "done"?

• Review comments do not overlap.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a developer I want to regularly remind users that we need support to continue to exist so I can hopefully raise enough money to keep this thing going.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We don't want to pester users for support on every visit, but we do want to remind them at regular intervals that we need support. Ideally we'd have a way to track whether they've supported us, but that's not an immediate feature. For now, lets just pop the support notice back up at the beginning of each month to remind them that we will need support. Then they can dismiss it and it won't reappear until the next month.

Acceptance Criteria

At what point is this story considered "done"?

• The SupportNotice reappears at the beginning of every month until dismissed again.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a [who] I want to [what] so I can [why].

Story Background

Author:

What is the history or background behind this story? What context the developer researching or implementing this story need?

Acceptance Criteria

Author:

At what point is this story considered "done"?

• Criteria 1
• Criteria 2

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

We need to protect most of the User endpoints (and probably most endpoints) with an authorization system that ensures only people can only modify resources they have permissions to modify.

Some endpoints, like POST /users should remain mostly open. But others, like DELETE /user/id need to be restricted to only the user and admins.

As a user I want to be able to edit my profile to update my name, email, and password so I can keep my information up to date.

Story Background

Author: danielbingham

What is the history or background behind this story? What context the developer researching or implementing this story need?

We need to create a user profile page and then allow them to edit to their profile. We're going to use this story to introduce React Router and the beginnings of basic routing into the front end. We're also going to use it to introduce some proper constraints to the database (emails must be unique) and report those errors back to the registration form. For now, we're not going to worry about authentication.

Acceptance Criteria

Author: danielbingham

At what point is this story considered "done"?

• We have introduced React Router and set up some basic routing
• We have created a /user/:id/display-name route on the front end
• The RegistrationForm redirects to the /user/:id/display-name page on successful completion
• Backend errors prevent the RegistrationForm from completing and are displayed in the form

Dependencies

Author: danielbingham

What stories does this one depend on? What do we need to do first before we can call this one done?

No dependencies.

As a user I want to sort and paginate the Field List so I can see the fields I want and not be overwhelmed.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We need to be able to paginate and sort the user list. We'll offer sorting by Newest, Active, and Reputation.

Acceptance Criteria

At what point is this story considered "done"?

• UserList is paginated showing 30 users per page in 6 rows of 5 user badges.
• UserList can be sorted:
  • Newest most recently created users.
  • Active users who have published recently.
  • Reputation ordered most reputation to least.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a developer I want to build a unit test framework and initial unit tests around my code so I can have test coverage and have confidence in the changes I make.

Story Background

Author: danielbingham

What is the history or background behind this story? What context the developer researching or implementing this story need?

In #3 we did some research into unit tests and decide on Mocha, Chai, and Sinon. Now we need to actually build the initial unit tests. Ideally, we'd have unit tests around both the frontend react/redux code and the backend express code.

Acceptance Criteria

Author: danielbingham

At what point is this story considered "done"?

• We have Mocha, Chai, and Sinon set up and a test harness in place.
• We have written appropriate unit tests for the code that has already been written.
• We have confirmed that those unit tests run and pass.

Dependencies

Author: danielbingham

What stories does this one depend on? What do we need to do first before we can call this one done?

No dependencies.

As a [who] I want to [what] so I can [why].

Story Background

Author:

What is the history or background behind this story? What context the developer researching or implementing this story need?

Acceptance Criteria

Author:

At what point is this story considered "done"?

• Users can click a link to see the list of versions
• Users can upload a PDF as a new version of the paper
• The version of the paper is incremented and the newly uploaded PDF is tagged with it

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

As a user I want to be able to change my settings (ignored fields, isolated fields) so I can choose which fields I want to pay attention to.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?
We need a user settings page where the user can change a variety of settings. For now it will just include which fields the user wants to ignore, or which fields they want to isolate (only view). In the future it will almost certain contain additional settings.

Acceptance Criteria

At what point is this story considered "done"?

• We have a UserSettingsForm that can be plugged into the UserAccountView.
• The UserSettingsForm has two tag fields which allows users to select tags to isolate (see only papers tagged with those fields) and tags to ignore.
• All paper views (published and draft) respect the isolate and ignore settings. The isolate settings are applied first, and then the ignore settings (allowing users to ignore subfields of fields they've isolated - EG. isolate physics, but ignore quantum-physics).

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a Author of a Draft I want to be able to accept or reject reviews on my drafts based on whether or not they are helpful to me so I can reward those who provide helpful reviews and dismiss reviews that aren't helpful.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We want to put control of the pre-publish editorial process in the hands of authors. To that end, we want them to be able to accept or reject reviews based on whether or not those reviews provided helpful feedback. Accepted reviews grant their author some amount of reputation. The working amount will be 20 reputation granted per accepted review. Users can only gain reputation from a single accepted review per version of the paper.

Acceptance Criteria

At what point is this story considered "done"?

• Authors have "Accept" and "Reject" buttons under the summaries of submitted reviews.
• Accepted reviews grant the reviewer 20 reputation.
• Reviewers only get reputation for one review per draft version.
• Rejected reviews have no impact.
• Close reviews (accepted or rejected) are shown below open reviews in the review list.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a use I want to be able to paginate and sort the DraftPaperList so I can highlight the papers I want to see and not be overwhelmed by sheer volume.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

Similar to Issue #42 , we need to sort and paginate the DraftPaperList on the Reviews page and the My Drafts page. Actually, these are two component trees that are basically the same right now. They need to be refactored and combined into a single DraftPaperList. I might get to that before I get to this issue, but if I don't, it should happen as part of this issue.

Acceptance Criteria

At what point is this story considered "done"?

• DraftPapersAwaitingReview and DraftPaperListView have been combined into a single DraftPaperList.
• DraftPaperList paginates its query results, showing 50 papers per page.
• DraftPaperList is sortable:
  • Newest shows the most recently published papers first.
  • Active uses an algorithm based on votes, responses, views, and papers.updated_date. Algorithm to be determined.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a developer I want to use DigitalOcean Spaces for file storage on staging and production so I can store objects in CDN storage with out mucking about with volumes and maintain a state free backend.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

For locals we're just using the local file system to store uploaded papers, but that won't work when we actually build a production cloud infrastructure. We'll want to use some sort of object storage. We're probably going to start out with Digital Ocean's cloud because of it's cheap and transparent pricing, so we'll start with Digital Ocean's Spaces for Object Storage.

Acceptance Criteria

At what point is this story considered "done"?

• We have a wrapper around Digital Ocean spaces that slots into the FilesController and replaces local file storage when the environment is staging or production.
• We have a wrapper around local file storage that can be used by the FilesController for locals.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a [who] I want to [what] so I can [why].

Story Background

Author:

What is the history or background behind this story? What context the developer researching or implementing this story need?

Acceptance Criteria

Author:

At what point is this story considered "done"?

• User can request a password reset
  • User is presented with a form to enter their email
  • User is email a link with a token that takes them to a password reset form

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

As a user I want to be able to post public responses to published papers so I can offer critique, criticism and feedback.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

On the published paper view page, we want users who have enough reputation in the fields the paper is tagged with to be able to post responses to the paper. Those responses should be markdown formatted. "Enough reputation" is an open question. We'll probably start with 1000 reputation in at least one of the fields the paper is tagged with.

We'll need to change how papers are displayed on the Published Paper page for this to work UX wise. We'll need to show only a single page of the paper at a time, with controls to go to the next page, previous page, or jump to an arbitrary page (and a control to show what page you're on out of how many).

Acceptance Criteria

At what point is this story considered "done"?

• Users with 1000 reputation in any of the fields on a paper are presented with a "Post a Response" form on the Published Paper Page.
• The form contains a textarea and a submit button.
• Submitted responses are Markdown formatted and displayed beneath the paper.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a [who] I want to [what] so I can [why].

Story Background

Author:

What is the history or background behind this story? What context the developer researching or implementing this story need?

Acceptance Criteria

Author:

At what point is this story considered "done"?

• Paper becomes PUBLISHED
• Must be confirmed by all author users (non-existing users are emailed and asked to create accounts -- given a link to confirm without account creation?)

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

As a user I want to have my choices saved to my session (eg. dismissing a notice) so I can not have to take the same action repeatedly.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?
We currently show multiple notices on the Peer Review homepage (one describing what Peer Review is, one requesting funding, and one announcing that this is alpha software). Users need to be able to dismiss those notices and have them dismissed for the duration of a session.

Acceptance Criteria

At what point is this story considered "done"?

• A user can dismiss the notices and they stay dismissed for the duration of the session.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to be able to update my draft with a new version and get another round of review so I can fix issues found and continue to iterate on my paper.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?
We already have the concept of paper versions in the database. We need to expose a UI to upload a new version of a paper from the DraftView/Review screen. And we need to expose a UI to view past versions and their reviews. Reviews should be tied to the version of the paper, not just the paper. So reviews on an older version shouldn't show on a newer version.

Acceptance Criteria

At what point is this story considered "done"?

• There's an "Upload New Version" button on the DraftPaperView/Review screen.
  • When clicked, it presents the user with a form allowing a new version of the paper to be uploaded.
• Reviews are tied to versions, so reviews given to version 1, don't show on version 2 and vice versa.
• The "reviews" and "my draft" list show a "reviews" box and a "version" box on the left hand side of the list item. The "reviews" box lists the number of reviews given to the current version and the "version" box show the version we're on.
• On publish, we take the content from the final version and put it in the contents field on the papers table - we'll use this to implement search later.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a user I want to sort and paginate the published paper list so I can see the papers I want first and not be overwhelmed with the whole list of papers.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We'll need the paper lists to be sortable and paginateable so that we can handle a lot of papers.

Initially, we only need a couple of sorts:

• Newest shows the most recently published papers.
• Active shows the papers with the most recent activity (using some combination of views, votes, and responses).

Discussion Item: Do we want to include a "most votes", "most views", or a "most responses" sort?

Acceptance Criteria

At what point is this story considered "done"?

• The PublishedPaperList is paginated with 50 papers showing per page.
• Users can sort the PublishedPaperList by Newest and Active.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a [who] I want to [what] so I can [why].

Story Background

Author:

What is the history or background behind this story? What context the developer researching or implementing this story need?

Acceptance Criteria

Author:

At what point is this story considered "done"?

• Votes on Reviews affect the review’s author reputation
  • Up votes give 5 reputation
  • Down votes take 1 reputation
• Should authors be allowed to vote on reviews of their papers? (probably not)

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

As a developer I want to show errors to users in a consistent way so I can easily report errors and get bug reports back.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We need a simple error modal we can pop up for unrecoverable errors so that we can see them and so that users can send us bug reports.

Acceptance Criteria

At what point is this story considered "done"?

• We have an ErrorModal defined as a top level component that we can give a "message" as a prop.
• We have an Error boundary defined and wrapping our whole app component that will pop up the error modal for uncaught errors.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?

As a [who] I want to [what] so I can [why].

Story Background

Author:

What is the history or background behind this story? What context the developer researching or implementing this story need?

Acceptance Criteria

Author:

At what point is this story considered "done"?

• User can post a PDF as a paper
• Paper is marked as draft for feedback
• Paper is added to paper versions as version 1

Dependencies

Author:

What stories does this one depend on? What do we need to do first before we can call this one done?

What are we doing?

Author:

How do we plan to solve this story? This should include a detailed plan of attack with prototypes, designs, and a description of any proposed code changes.

What are the alternatives?

Author:

What are the alternative solutions we considered, but ultimately decided against?

What are we not doing?

Author:

Is there anything we explicitly decided not to pursue as part of this story? Why?

As a user I want to be able to search published papers so I can access the literature and do my research.

Story Background

What is the history or background behind this story? What context the developer researching or implementing this story need?

We need to implement the alpha version of paper search. This will just be full text search against the paper's titles and body content.

Acceptance Criteria

At what point is this story considered "done"?

• We show a search box on the home page.
• Users can use the search box to search the full text of papers and their titles.
• Search results respect their tag settings.

Dependencies

What stories does this one depend on? What do we need to do first before we can call this one done?