1. Spreadsheets improvements (very large)
- Convert tables to use React
- Outstanding issues (ordering of columns is still a problem)
- UI improvements: Anchoring the first column for better horizontal scrolling
2. CSV upload/downloading
The semantics of the different uploading features is varying and unclear. We especially need to take a close look at the uploading of data in to the spreadsheets, groups, and graders views. Working on this project will require a deep understanding of the operation of each of these uploading functions, looking at the database and repository operations, and documenting the behaviour in the help system.
The other area where CSV uploading needs improvement is that we sometimes encounter performance problems where Apache seems to time out.
3. React refactoring (smallish)#1696
In the past two terms, we have converted tables to use the React library. As we near the end of this process (spreadsheets are the last ones), the code for the tables could use some refactoring to simplify it and pull together common functions.
4. Get rid of the rest of Prototype #1496 (small)
We encountered some bugs with the remark request system, and have some feature requests. This will involve the remark request view and the marking scheme models.
5. Git backend #1698 (large)
Alex worked on the git backend last term, and is planning to finish it this term. The main piece that is left is incorporating authentication so that students can use git directly. He is planning to work on it again this term.
6. Rails 4.2 upgrade
A lot of work has been done to upgrade MarkUs to use Rails 4.x. There is still some work remaking to complete this upgrade. This project would be a great one for students with some understanding of Rails, and have an interest in how the Rails framework works.
7. Rspec tests (large, but an ongoing effort)
This summer saw a major effort to change to Rspec tests. In the fall we were successful in getting all students to write some Rspec tests, and Kuba also spent the term refactoring and testing the Assignment model. A continuing goal is to have everyone on the team write some Rspec tests. It will be a good way to really learn what the models and controllers are supposed to do, and will move the project forward. We plan to set aside a few hours at the sprint for writing tests. There are some outstanding Github issues related to missing tests that can easily be closed with some work.
8. Improve seed data for the development environment
In the dev environment, there is data to populate the data base with users and assignment submissions. This seed data helps with manual testing and understanding how the system is supposed to work. We need to increase the size of the seed data to include more students, more assignment submissions, and to increase the diversity of initial scenarios such as different due dates for submissions that affect more of the system.
9. Summary page of all the marks for all students (smallish)
There is currently no view that combines marks from all of the different assignments and spreadsheets. This table would look a lot like the Submissions table or the Summaries table, but would have one column for each assignment and spreadsheet. A new feature would be a way for the administrator to specify a weighting for each piece of work to produce a total. (Good for someone not familiar with Rails.)
10. MathJax support for annotations? #285 (medium?)
It would be nice to be able to use math symbols in annotations. The MathJax library seems to be what we want, and some work has been done on this.
11. UX Refresh of the submissions table (Includes #75) (medium)
We haven’t taken a serious look at what is in the submission table for a long time. For example, we probably don’t need the “can begin grading” field. We would also like to be able to show the grader(s) for each group.
12. Section due dates don’t work #1676 (small)
Some courses would like to have a different due date for each section. This feature seems to have numerous problems with it. There is also a proposal to change the UI for how sections are added.
13. More flexibility in the marking schemes
There are lots of ways in which the two available marking schemes could be improved.
14. API improvements
It would be nice to make the API more powerful so that we could take more advantage of the API for automated operation. This will also involve writing some scripts and consolidating scripts that interact with the API.