Closed Bad-Science closed 6 years ago
Comment on section 1.: we should setup interviews with key stakeholders in this. I suggest contacting their registrar and secure an interview. Additionally, we should interview some students and have them demonstrate the process of signing up for courses so we understand their pain points.
Great suggestion @MJGTwo! Thanks! I wonder if the NYU folks could suggest some local stakeholders, and help with a plan to interview local students. We should open an issue for this and add this to the scope in a new PR.
Hi all, I am the NYU leader of this project and am looking forward to working with you all.
As many of you know NYU is a very large school with an undergrad population of over 25,000. However, there are two campuses/schools one in NYC, with a population of over 20,000 which has the College of Arts & Science (which has CS and Math), Professional Schools, Arts School, Individualized studies, business school, education school and others. The Brooklyn campus is called Tandon and it is the engineering school. That school has a population of over 5,000. I think that is a great place to test the software first since students on that campus take most if not all of their courses there.
Regards to the NYU course catalog, they do not release the number of seats available in each course publicly. I do not know if we can get access to this information. Here is the link to the catalog which was just make public this semester, https://sis.nyu.edu/psc/csprod/EMPLOYEE/SA/c/NYU_SR.NYU_CLS_SRCH.GBL?&
Please let me know what kind of students you want to interview and I can organize that.
I like to compare registration to playing the stock market. Especially at NYU it is complete hell! I think this software can really help alleviate some stress and make the process better for students.
If you have any questions feel free to contact me, Richie has my info.
Thanks @bradleybrecher for the info! We can discuss the details of the research we want to do during our upcoming call and report back here. We are looking forward to working with you as well!
This is a first draft of the proposal outlined in #1
Please make comments, ask questions, and suggest changes!
The proposal can be viewed in the Files Changed, but is copied here for convenience...
YACS @ NYU!
Intro
The YACS team, as well as everyone at RCOS is very excited to be starting this collaboration with BUGS. This effort has the full support of the RCOS administration, and we mean to support this integration and long-term collaboration however we can. We hope that this is the beginning of a strong and fruitful relationship between our organizations.
Scope
The ultimate goal is to provide the full YACS experience for the whole of the NYU student body. There are a number of needs to be met in order to make this a reality.
Determine what changes need to be made to YACS in order to make it 'compatible' with NYU:
YACS was designed to be as university-agnostic as possible, but there were assumptions we made that might not make sense at NYU. These could be ways we store data, data we currently rely on that NYU may not provide, or information we display to users that may not be applicable to NYU students.
Conversely, there are likely many additions that could be made that would make YACS significantly more useful to NYU students than it is in its current state.
The task here is to, first, look over the app carefully and document what changes should be made. For each proposed change, an issue should be opened in the appropriate repository.
We anticipate that most of this work will be frontend development.
Create a service to pull data from NYU's systems and convert it into a form YACS can ingest.
At the core of YACS is a data pipeline that can ingest data from a variety of different sources with little configuration. The caveat though is that YACS expects the data to be organized in a specific way. So the task is to create a program that will continuously poll NYU's systems for data, transform that data, and present it as a JSON API for YACS to ingest.
Obtaining this data in the first place can be challenging. One option would be to 'scrape' the Albert system every so often and watch for changes. This would work, but it would be innefficient, difficult to maintain, and prone to breaking.
A better solution would be to find, or convince the relevant administrative body to provide a better way to programatically access that data. We were able to achieve this at RPI after demonstrating the value YACS had to the students and faculty, and we hope the same will be possible at NYU.
If the administration at NYU is anything like RPI's however, this may take some time. Therefore, a reasonable approach may be to start by creating the system to scrape Albert, with the hope of replacing it soon. Even if it is replaced, it will likely be helpful to have as either aa fallback or reference implementation later.
Deployment
YACS handles a load of roughly 6000 total students at RPI, and does so happily on a single, relatively old machine. NYU is much larger than RPI, however, and it is possible we may encounter some scaling issues that will need to be resolved. Additionally, we may find that there is more feature development needed for NYU students to get the most out of YACS after we launch. For these reasons, we will be starting with a 'soft launch' at the Brooklyn campus only. The Brooklyn campus is roughly the size of RPI, and this soft launch will allow us to better find and fix problems and get feedback from students before we launch YACS for the entire university.
Other Work
In addition to any NYU-specific tasks, there is plenty of general work to be done on the project. The best list of ready-to-go issues that can be worked on is https://github.com/orgs/YACS-RCOS/projects/3. Note that in order to see this board, you must be a member of the organization, so send me your Github name or comment here to be added.
Conclusion
This is a working document (for now at least), and is only an initial proposal. Our goal is not only to launch YACS at NYU, but to provide BUGS members with a valuable and fulfilling experience, and to foster a general relationship between BUGS and RCOS. To that end, and to the success of this project, the input and perspective of the BUGS contributors in all manners is extemely valuable.
So, give this some thought, make some comments, and let's get to work! And most importantly... HAVE FUN!!