General Engineering Projects/History/Version 2

The creative, formless part of this version can be organized through the CDIO syllabus. Using this language, the goal is to negotiate with each team, each week the documentation outline. Perhaps it takes four weeks to create a CDIO document. Perhaps a single student creates a CDIO document overnight.

The importance of public versus non-profit or non-commercial means that the goal is to expand the Knowledge Commons, not promote a person or institution. This means giving up attaching categories with school names or using "I" in any wikiversity document. It means avoiding trademarked phrases, names, etc. It means removing a time context. A knowledge commons should not have dated material in it. It should have bigger context .. a history.

Use of Categories

The college and college semester categories have not proven useful. Colleges/Schools/Universities can point to wikiversity project pages with their own web servers for marketing, recruitment, and course delivery. A method for them to exist within the wikiversity through categories defeats the long term objectives of wikiversity and have not proved useful.

• General Engineering Projects
• General Engineering Tutorials
• College
• College Semester

The last two categories would disappear.

General Engineering Tutorials

The goal is to use the caption section of photos to capture steps rather than text between the photos. This will enable the photos to be put in different orders, re-used in different tutorials. The expectation is that different tutorial categories will evolve to the point they become macro tutorials.

General Engineering Projects

The goal of general engineering projects is to capture the creative design process of engineering as it unfolds with these objectives:

• Others can jump in, find a starting point and push the project forward
• Existing documentation serves as scaffolding to quickly build up expertise
• Instructors can see previous task evolution, time and materials consumed for planning purposes
• Opportunities for casual readers to read through problems and suggest solutions
• Become a best practice implementation of introduction to engineering course

Use of SubPages

Information was not floating up from user pages into the project, semester, college levels and finally project (or world) levels. The lesson learned is that the information has to be created and polished in user space and then published once into article space with no SubPages or stubs.

User versus Article Space

Most editing occurred in student user space, but there was no formal grading process that encouraged publishing detail in article space. This resulted in most detail remaining in user space.

There was too much live article (project) editing. Detail that did reach this level was buried beneath college, semester and team links. Even the most determined searcher can not find much useful.

Article structure

Currently the article space looks like this: project-name/school-name/semester/team-name with links to student user pages

This will change to project/CDIO ... CDIO space would be flat and contain the names of Conceive, Design, Implement and Operate documents in traditional wiki style ... without reference to people or place.

Discuss page usage

The discuss pages of students in user space were used for grading with success. However there was no vision for the discuss pages associated with projects. Students never learned to discuss articles.

Project team pages were grading in article space discuss pages. This turn into grading in the student's user discuss pages.

User space usage

Turning instructors and students into wiki editors is not just the process of editing articles. User space has a context that needs to be learned. Teaching students to develop a "portfolio" in user space of their engineering projects was successful. However, instructor user space was not leveraged.

Identifying Instructors and their Student Wiki IDs

Before it was impossible to tell who was a student and who was an instructor. Now instructor names are in the discuss pages of general engineering project articles. Instructors have names of their students in their user pages. Now wiki editors can figure out who is a student and who is an instructor.

Forms

There were three forms or blank wiki pages with categories to be filled out:

• World
• College
• Team

Finding the forms was difficult and they did not capture useful information once filled out. Five new forms are proposed: project, conceive, design, implement, operate. Two additional forms: weekly report and team page would be in the student and instructor user space only. There are plans for the discuss pages of each of these.

Article Creation

A engineering project documentation strategy has been extracted from the CDIO syllabus. CDIO has a chance of evolving into a world wide best practice standard for engineering education project documentation. This adds specific form to the the project documentation proposed.

The proposed structure creates an article for each project as before, but with only one level of subpages/stubs. Instructors are encouraged to keep track of teams and students in their user pages.

Students work in their user pages as before, but in addition work on CDIO documents in their users space. After instructor approval, they publish (move/copy) their document from user space into the project article space.

Instructor names appear in the project discuss page only when they have students actively working on the project. This way multiple instructors at the same or different institutions are encouraged to coordinate/cooperate/negotiate how the projects evolve.

Student and college/school names do not appear project article space ever.

Article structure

Engineering projects will have a simple, article type of name. These names will probably change over time. Most projects will morph over time. For example a project called "Snake Hat" started off with the objective putting LED's in a plastic rubber snake on a hat and lighting them up. The project name could have been "LED projects". But it developed sensors to detect moods, so the project name could have been "BioFeedBack." But this evolved into a straight jacket covered with EL wire, switches and LED's with an EEG hat from a star wars game and blood pressure cuff read by an arduino.

Open-ended projects often spend more time in Conceive and Design rather than Implement and Operate. CDIO generates four chances to celebrate success. CDIO allows projects to fork and create a tree within the CDIO context. Projects don't have to be driven all the way to Operation to feel "finished."

The current context doesn't capture engineering, doesn't generate a sense of success, and creates a context that cripples the feedback loop within all engineering projects. The reason is that the downstream context such as school, semester, team that looks valuable. Nobody wants to touch it. Everyone wants to avoid it or delete it. The theory is that when people, institutions and time are removed from the actual article structure, projects fork easier. And this fits the wiki context.

Example

CDIO subpages of article pages

CDIO is a world wide organization that evolved out of MIT aerospace engineering. As of fall 2012 there are 90 members worldwide including 15 US Universities.

CDIO has a chance of evolving into a world wide engineering accreditation organization. For a better introduction, read this general engineering introduction wikibook page.

Project pages would link to CDIO documents that come from cdio.org's syllabus.

Each project documentation article will have at the top two sections:

• Next Steps
• Poster

Each project documentation article could reflect anywhere from a week to a semester's amount of work by one person or a group.

CDIO Maximal Set

The four CDIO syllabus sections below are a maximal set of possible engineering tasks that need to be documented. No project or CDIO document is expected to do all of tasks.

• Conceive CDIO syllabus section 4.3
• Design CDIO syllabus section 4.4
• Implement CDIO syllabus section 4.5
• Operate CDIO syllabus section 4.6

The CDIO maximal set is very thorough. It might take 2 hours per bullet point just to explain what each means in an engineering context. Most engineers don't experience all bullet points or even experience them the same way. The goal is find a representative set that form the outline of documentation for the purpose of a freshman projects class. The objectives of this minimal set are:

• drive instructors into CDIO maximal set when managing freshman projects
• find a common form so that the CDIO project pages can be quickly compared
• captures details independent of success or failure
• limits the engineering concepts that need to be explained to freshman
• minimizes the number of common words that need to be redefined in an engineering context

CDIO Minimal Set

The CDIO Minimal Sets below differ from the Maximal set in the wording and numbering of the subsections. The overall bullet points are the same.

• Minimal Conceive
• Minimal Design
• Minimal Implement
• Minimal Operate

The CDIO Syllabus was intended to be a logical context of engineering objectives. It was never intended to capture project documentation. The outlines above don't leverage all that is in the CDIO syllabus. For instance the first thing freshman engineers want to do is "research" which is a buzz word associated googling what they can about the project. It results only in the personal fruit of informing themselves. Nothing is created or accumulated that the entire word benefits from.

Rather than fight freshman by saying "research" is evil, the goal is to turn "research" into a task and define at which CDIO level it is done at. Perhaps it is done only at Conceive. Perhaps it is done at each of CDIO but results in a research document with references that is published. The goal of tasks are:

• Meet freshman half way .. expand/refine their vocabulary
• Instructors grow the task list .. defining each within the CDIO minimal outline above
• Slowly expand the task list on an as needed basis
• Map tasks to other parts of the CDIO syllabus

CDIO tasks

Each task should result in a documentation deliverable in the CDIO minimal documentation context.

Tasks are a maximal set, not a mandatory minimum that freshman engineering students are marched through. The project itself determines which tasks are selected. Tasks are chosen in a negotiation between instructor and individual students on a team or the project team. They are a starting point of tasking discussions.

A beginning set of tasks (short phrases) has been developed that parallels the CDIO outlines above. Eventually each of these will be linked to a short descriptive paragraph.

Each of these CDIO pages will have a task history associated with them in their discuss page.

User page useage

Student

Student user pages would continue to build a portfolio of their work during the semester. Grades would appear in the discuss pages of their weekly reports.

CDIO documents that were polished in user space and transferred to project article space may remain, be linked to the live document that is perhaps being edited by another team, or just be deleted by the student.

The student should have links to the team page in the instructor user space, links to their weekly report pages and links to the CDIO pages they are actively working on.

example

Instructor

The instructor user pages are the natural place to keep track of teams, link student names to their user space, and grade. This information doesn't need to be in article space as it is now. And it doesn't need to be in an instructor discuss page. Students could link back to it in their personal space to see CDIO document grading.

example

A summary of the team CDIO pages is created by the instructor from this information in the CDIO discuss page.

Discuss page useage

The proposal is to expect communication between people on the discuss page. This keeps personality and place out of wikiversity article space.

One problem with this is that the history part of project pages will not adequately capture engineering information. Project pages need a history of CDIO documents added/modified/combined into one, etc. Looking through CDIO history and project history to piece this together is never going to be done. So an edited history is proposed in both the project and CDIO discuss pages.

Project

Project discuss page will have only the instructor's wikiversity userid and names of CDIO documents that their teams are working on. This will serve the purpose of helping instructors across the world coordinate, cooperate, duplicate, fork and discuss projects.

After the project is over, after students have created the CDIO page, after instructors have approved it, students have moved it out of their user space into a project stub and linked the main project page to it, then the instructor removes their name and updates the project's discuss page with what happened.

example

CDIO

Each of the four types of CDIO pages would have a history in it's discuss page. This is a history of previous tasks and total time spent creating that CDIO page. The goal is to enable engineers, instructors and students to estimate project materials, time, and personal needed. The goal is to generate a scope for planning purposes.

Another goal is to help show how the project was split up into tasks. Often the tasks assigned students hit dead ends. These need to be documented. Expressing the tasks in a certain order often speeds up the project. For instance, focusing everyone on the crank shaft design in strandbeest projects speeds everything up. The tendency is to focus on the legs first.

example

Instructor

Instructor discuss pages could be used by other instructors to discuss who/what/materials/when with other instructors ... in more detail than the project page. The instructor discuss pages would more likely be used by other instructors at the same institution.

Student

The students discuss page would have grades from the instructor and personal comments from other team members. Currently team members are encouraged to say something positive on each team mates discuss page (associated with the weekly report) once a week.