Let's get the ball rolling on staff positions for this.

@rawatson This is your call, https://travis-ci.org/ is free and I think would help us bug track.

I am writing pre-commit checks that use jshint to check our Javascript against Javascript community coding style recommendations, and rubocop to check our Ruby against the Ruby style guide

As a standard for Angular code, we should follow the Angular style guide to structure our Angular code.

Please check out these standards @maesenc @anthonymainero @rawatson, so we can have a consistent codebase. I don't think there's currently a way to automatically enforce the Angular style guide, but for the Ruby and Javascript stuff, I'll make a script that is triggered on every commit to check it, and instructions for how to activate syntax checking in your editors.

The sorts of things that would be useful to slap on the wiki page are:

• Who is knowledgable about the existing CS198 infrastructure and how closely tied we are to existing infrastructure?
• What group of people would be willing to regularly give us feedback on/test out our work? Largely SL's, but a list of reliable candidates/an actual beta mailing list would be good.

Anything else you think we need contacts for, comment below.

Right now, everything is tested by hand - unreliable.

More appropriate for our needs:

http://angular-ui.github.io/bootstrap/#/popover

Rasmus Rygaard suggests that we allow section leaders to build up a repository of common issues, and be able to refer to them like github issues (you can refer to an issue in github with the number of that issue, just by typing the issue's number, like so: #1).

If there was some way of discovering common issues, it would be very convenient not to rewrite and copy-paste the same problem on many students' submissions. It would save a lot of time.

Development on the CS198 website effectively ended in 2007-2008, when all of the primary authors graduated. Development on paperless saw a similar cycle. We don't want this project to be completely rewritten in 2016, so we need to think carefully about how to keep the project alive and actively developed in the CS198 program.

• When we choose tools and technologies: how can we choose products which are easy to work with and more likely to be known by current and future section leaders?
• How can we structure our coding and design process to simplify the project even as the requirements grow more complex?
• How can we structure the project to encourage easy contributions from SLs who see something they'd like to add or change?
• Is it possible to designate a role of "tools maintainer" in the CS198 program? Can we adapt this to be a semi-permanent SSL type role?

We are using prior sectionee code for seeding data, and it's in our public repository. In essence we've publicly released a bunch of people's code and solutions for CS106A and B, which is probably an honor code/fundamental standards violation.... we should get rid of it as soon as possible (after the demo), especially before opening this to further SL development.

Dependency: Migrating from CS198 db.

Detailed issue description: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

Wrap all API calls with an object, for consistency:

{
  "data": <the juicy stuff>,
  <metadata, like response message, errors if it was a failed request, etc>
}

RJ Walsh requests that we implement at some point the SL Family Directed Acyclic Graph detailed here, or some form of it. Could be a fun feature :)

Current structure disallows people having different roles in different classes. Lame! Use authentication + querying for role to get the role.

TA says that WebAuth may only be accessible from within the Stanford Network. This is restricting, let's see what the Stanford IT dept says.

Please fix!

When we discuss, let's talk about things related to the design process as taught in the d-school and by HCI people. As explained in CS147, that includes these steps:

1. Needfinding
2. Rapid prototyping
3. Heuristic evaluation
4. Experimenting
5. Repeat

I think it can be useful to have a formal structure to the way we approach building features and evaluating them, since this will be a real product unlike many CS194 projects!

When choosing a course, its navigation selector collapses. same for submissions. but not for assignments :(

Problem

We are currently using SyntaxHighlighter.js to highlight code syntax. To use it, you do:

<pre class="brush: js">
// js code
</pre>

There are two problems:

1. you need to specify handle languages dynamically. A js file should have the "brush: js" class, and needs to include its associated "brush" file. Each language has it's own associated javascript "brush" file that will also need to be included.
2. In a pre tag, you need to make sure that an open bracket symbol (<) NEVER shows up the code. It needs to be escaped, like so: <. Otherwise, the pre tag will not render properly.

Proposed solution

Make Angular services that handle both of these things.

Find out if there are any license restrictions for CS198 software usage.

Refreshing the page they show up ~50% of the time

• What machines would our code run on?
• How much control do we have over the environment they run in?
• What does availability/reliability look like?
• If we used our own machines/the cloud/other systems, how much will Stanford foot the bill?

Returning all of the submissions degrades performance significantly, and looks pretty bad

Assignments can be made but not released to students

We decided in the spec meeting that the website will probably be client-driven. So, let's decide on a frontend web framework.