RFC: Uphold Curricular Categories

[ghost]

No description provided.

[waciumawanjohi]

An interesting proposal. Some notes:

• The CS2013 states, "CS2013 should provide the greatest flexibility in organizing topics into courses and curricula. Knowledge areas are not intended to describe specific courses. There are many novel, interesting, and effective ways to combine topics from the Body of Knowledge into courses." While we use the CS2013 as guidance for course selection and evaluation, the guidelines do not expect that students must complete all of a knowledge area at once.

• We do structure OSSU:CS to facilitate students working through the courses in order. "For simplicity, we recommend working through courses (especially Core CS) in order from top to bottom." Students often reach out for advice on course ordering, there is evidence that this prescriptive approach benefits students.

• The RFC states "The following curriculum structure its proposed to address the problem:" but what follows includes many changes to the curriculum that go beyond the curriculum's structure, courses have been added and courses have been removed. Opening an RFC on a single issue allows contributors to have focused conversations. If you would like to propose different courses for a topic, please break those out into separate RFCs.

[waciumawanjohi]

• "Knowledge Areas are not intended to describe specific courses, but that doesn't mean that a KA cannot be used as guided categories for courses."
  With this in mind, can you elaborate on the problem that this RFC is targeting? The change you propose would rearrange all courses for students; what benefit will OSSU students gain from this disruption?

• "like you inaccurately assumed"
  This sentence fragment is unwelcoming. When I write a request for comments, I remember that I am asking others to take time and energy to give me feedback and to collaborate with me. I work hard to phrase my responses in a way that reflects that.

• "I added a note at the bottom of the RFC to avoid confusion" "Courses included are my personal preference and are meant as an example to fill the column, if the proposed organization by Category and Knowledge Area is accepted, the courses will be changed to match the specific ones that OSSU has made available at that time."
  Can you remove the information that is not relevant to the RFC from the RFC? When presenting something complicated, it is better to simplify it, rather than to tell reviewers to ignore the complication.

[wybrenl]

Interesting discussion, 2 thoughts and consequent alternative to consider

• Based on questions/discussions I see in discord my hypothesis is that topological order benefits students more than KAs.
• I do believe there is merit to showing how the OSSU curriculum maps to CS2013 KAs because it helps learners to understand the big ‘chunks’ in CS, and allows them to determine where the curriculum is rich on content and where potential gaps are.
• As an alternative to consider: add a mapping of the current OSSU courses to KAs on the OSSU page where curricular guidelines based on CS2013 are presented (https://github.com/ossu/computer-science/blob/master/CURRICULAR_GUIDELINES.md)

[bradleygrant]

It appears to me that the whole entire approach to the redesign is to arrange it in such a way that it makes it plain to see we've checked all the boxes in CS2013. That's a good quality control check but it does not improve the curriculum.

OSSU isn't a mere course listing. It's a curriculum. Curricula have opinions not only on what is presented but also when it is presented.

So the problem with this approach is there's no direction on how to take the courses or in what order. It's not reasonable to assume that one will deep-dive all of the Systems courses before taking any of the Applications courses. Just like there's no reason one needs to do all the Math courses before doing any of the Science courses in a Physics degree, for example.

I think the best use of a deep-dive such as the one you've presented is as an internal auditing and course selection tool. Not as a front-facing curriculum update or curriculum supplement.

The good news is there has been need for an internal auditing and course selection tool. A course competencies matrix has been envisioned for some time, but hasn't been executed as of yet. Would you be willing to consider assisting with the development of such a tool?

[waciumawanjohi]

I should note that CS2013.org has a ready made spreadsheet for evaluating curriculum coverage. As Bradley Grant states, OSSU should carry out an evaluation of the curriculum against this spreadsheet. I've had some ideas knocking about regarding how to approach the effort. It's not a trivial undertaking.

Having such an effort live on the curricular guidelines page makes sense.

I'm don't think the structure above will give us the granularity that will be necessary for that review. I'll give as an example Introduction to Computer Science and Programming Using Python. It's an early course in the curriculum, and so we expect it to cover a fair bit of Software Development Fundamentals. But it also does a good amount of work covering data structures. A thorough review will get into this level of granularity.

With a thorough review complete, OSSU would then be in a great position to communicate that coverage to students!

[Exkywor]

I haven't looked too deeply into the proposal (yet), but is there a reason why we need to choose one option over the other? Could we not keep the curriculum organization as-is for students to know in what order to go through them, but also add this as an extra view of what is covered by OSSU?

[MOSTAFAEZZAT]

Absolutely YESS, This's pretty neat to the current and good for new fellow, i even struggled when i picked Software Engineering Path and searched a lot to know what courses from the circular I should take.