General Engineering Projects/History

General Engineering Projects are targeting high school seniors and college freshman ... those around 17 years old. The goal is to give them an engineering experience.

1800 to 2000

Originally most project documentation was done through drawings. By the early 80's, the vision of project documentation through simulation had taken root with Fortran or some other programming language. By 2000 the project documentation had to fit into the "joy" of and engineering "project" experience so they would continue in their STEM studies. This document reflects the current state of that process.

2000 to 2010

At first project documentation was a flurry of due dates and paper submission. Activities were 4 weeks of 3D drawing, 2 weeks of Matlab etc. The modules had no relevance to a project so the engineering discipline of learning just enough to do the project had no context in which to be discussed. Hands on building of anything was compressed to one week at the end of the semester. Everyone did the same thing. Results were compared.

HTML

Teaching electronic documentation did not change the experience much. Switching to HTML markup did. Suddenly students could produce all the documentation in real time, almost instantly. They would argue about the format. Due dates seemed random and arbitrary. An impatience with everyone doing the same thing morphed into a "any project, any time" chant that guided the course evolution. A formless expectation lead to a great deal of work by the instructor and a chaos of documents, spreadsheets, programs, pictures and data.

Every semester there were hints of success, but no success at leveraging this success. So various attempts at order were imposed. But it turned out there was a technology barrier. HTML lead to server side programming, includes, client side frames, and scripts that distracted students from engineering. The barrier turned out to be access to a common storage medium. The physical act of creating and transferring files to a shared location was too difficult.

The fruit of this experience was a KISS rule: Engineers needed something simple to document with. Colors and transitions, graphics and movement, backgrounds and fonts cluttered and distracted from an engineering conversation. Focus on error messages and failure descriptions was overwhelmed by a competition to stay on the edge of HTML/Javascript/client side programming.

LMS

Learning management systems began to provide upload abilities but engineering students either overwhelmed them or rubbed against the limitations exposed by HTML expectations. Various work arounds lead nowhere. Rigid implementation of limited HTML into a specific forms tied students hands but the HTML competition vanished.

The LMS solution seemed like the perfect balance of form and freedom until the DIY, open source software, open source hardware and hacker spaces began to take off.

Internet Expectations

When expectations of a first year engineering course began to be compared with DIY sites and what was going on in hacker spaces, something had to change. The "fun" component this movement represented had to be leveraged into teaching people how to be engineers. The open source licenses seemed to be focal point. Why were all engineering documents kept hidden inside an LMS, inside a filing cabinet, inside a book, inside someone's head?

If the internet was/is an accumulator, an integral, and documentation reuse becomes valuable, then so too should engineering project documentation. At a minimum engineers should utilize these emerging resources.

Looking back, there were lots of other expectations growing from the internet.

• What was the difference between inventing and engineering?
• Was there a better balance between form and freedom?
• Was the internet rich enough that students could find resources to polish their individual talents?
• Why can't I contribute to the internet?
• How is engineering documentation different from instructables, from thingiverse, how stuff works, HackADay, 3dwarehouse, from what Hackerspaces are doing?

2010 Wiki Version 1

What motivated a change from an in-house internal file service to wikiversity?

• editing in context
• saving in the cloud
• enforced balance between simplicity, form and freedom
• lower barrier to wiki markup than html markup
• no html evolution distractions
• open source licensing
• file type limitations
• graphic upload source checking
• wiki editor help
• public light improves freshmen behavior
• editing from any internet connected device
• great editing, contents, headings, pattern implementation

What lessons were learned?

Formless

A formless documentation philosophy drove the first version to see if:

• a consensus form emerged
• formlessness inspired unique, excellent documentation
• the wiki context would create a unique form

What emerged from this was the difference between a tutorial and engineering documentation. Students only felt comfortable creating tutorials. Otherwise there was not enough clarity.

Forms that were created were to support the world sharing a resource (see below), not engineering. Yet the forms were treated as really bad context for engineering documentation. The lessons learned were:

• forms created must focus on engineering
• everyone wants some structure when it comes to documentation
• don't try to re-engineer, extend or re-purpose wiki's .. conform
• the formless hypothesis was hidden in this fog and needs to be developed more in some kind of context

Leaving Room for the World

Worry about the light of public attention to a shared resource drove:

• developing a mechanism where schools, semesters, instructors, teams, would not step on each other's toes
• visualizing an information flow where technical details would float up from local to global
• creating an accountable/traceable/transparent review process for officials in local institutions

What actually emerged was no public attention. It is clear that just being on the internet doesn't automatically attract attention. In fact it attracts no attention. Wiki's seem to be organized expecting this.

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.

Authorship of articles is not to be apparent to the casual reader. There should be no personal crumbs to chase. In the process of trying provide a forum in which to cooperate, personal crumbs were left all over the place. What the crumbs physically do is stake out territory and thus chill any initiative to edit, temporarily own and polish in the public domain. All "I" conversations and even the development of "We" documents needs to occur in user space.

User Space

User space was not implemented appropriately. It is the place where it is appropriate to:

• be an individual and put I statements
• hold students accountable
• provide feedback
• practice wiki markup
• polish articles with multiple edits before moving to article space

2013 Wiki Version 2

Details of Version 2 have been replaced by Version 3. What follows is a summary of Version 2 changes.

Too much form

The creative, formless of version 1 was replaced with form of the CDIO syllabus. It was thought that the CDIO forms would add a common context to all projects and guide tasking of projects. Instead they caused these problems:

• Forms caused bloat that was painful to read, and almost impossible to edit. Time, place, personalities began to accumulate. Eliminating this was the goal of version 2.
• Too complicated .. too many forms .. too many discuss page, publishing rules .. CDIO turned into suggestion, placeholders.
• There was a shift in focus from project to form .. the project or problem stopped being the root of all discussions .. added "Problem" in front of CDIO in order to try and shift back to project focus

Subpages and stubs still accumulated making moving stuff from user space to article space impossible without involving a wikiversity editor and/or causing broken links. This was solved using the collapse tag or template and had the following additional benefits

1. Focus on sound bytes .. names of the collapse top tags
2. Everything can be put in one huge page .. no subpages or stubs
3. Outline at the top of the project is identical from project to project, no outline bloat
4. Free form documentation from Version 1 can be moved into this format with enthusiasm
5. Bloat reduction ... or the page becomes huge

Instructor user page

Instructor user space usage was expanded. Copying projects from the root article into instructor user space where students edit them. Multiple instructors could be working on the same project. Instructors need carefully edit the main project page with their student's work rather than replacing with a new version. The merging of forked project documentation back down into the root has to be done following wiki rules.

Student editing history of the new project documentation version will be lost. But because this occurs in instructor user space, the instructors are more responsible for their students messes and can clean them up easier. The goal is to turn students into fully functional wiki contributors. This is the best introduction possible.

Giving students project feed back in their discuss pages was not a good idea. It should be done in a more secured environment such as the schools Learning Management System or electronic gradebook.

Demo

Students and teachers operate within expanded fair use privileges of copyrighted material when presenting or demonstrating things to each other. However, when using wiki, these starting points can only be referenced. They can not be part of engineering documentation except through a reference.

Clarifying this issue is absolutely necessary to stop students from uploading copyrighted material and trademarks. Trademarks can appear in video's and pictures if they are accidental .. if they are incidental .. if display of them never is the intent of the picture or video.

These restrictions were never really a problem when engineering documentation was internal, proprietary, and unpublished work. In an educational setting this ethical boundary for engineering documentation has to be respected.

For these reasons, a demo section was added to the engineering outline. Demo means demonstration. Demonstrations can be a physical presentation, a video of a physical presentation or a slide presentation. When the presentation is an external link, then the content doesn't fall under wiki restrictions. The link can be to copyrighted work under fair use privileges.

So there are two ethical boundaries involved in respecting copyrights. The first is a public commons which can be used by anyone for any purpose .. including profit, non-profit, educational. This is what a wiki represents. The second is educational fair use which is accessed under demo.

Tasking

Tasking as visualized in version 2 was burdensome and fruitless. The physical tracking and accumulating of tasks may have been interesting from a research point of view, but it added no value to the project. The words used in tasking change meaning and morph rapidly when neither the instructor or student or society has prior experience with what is being attempted .. the very definition of engineering. Capturing this process can not be done in any kind of meaning full way except through a combination of design documents, pictures and video.

However, grading tasking did work in that it provoked more conversations between the instructor and students. What evolved was this interaction: student teams came up with individual tasks and presented them to the instructor. If the instructor accepted them immediately with no discussion .. maximum task points. If the instructor had problems with the tasks, points went down. If the students could not figure out the tasks, which forces the instructor to brainstorm, then points went down.

Next Steps

What evolved out of tasking were Next Steps. Next Steps appear in the weekly report and become tasks when negotiated with the instructor. Next Steps appear in the engineering notebook while reflecting in the RANT. Next Steps appear in the project documentation as advice of what to expect to be doing when starting up the project.

2014 Wiki Version 3

The CDIO syllabus and the INCOSE SE Handbook are good starting points for engineering documentation in general. Project management of large engineering systems over long periods of time involving lots of engineers requires a documentation framework with precise definitions and expectations. But this evolving organizational system is still unique to the project. Just like the rock or tree informs the sculptor, the project informs the engineer of it's documentation requirements. Making this beautiful is an important part of the process. Here is what is being emphasized:

• Instructors should use CDIO and or INCOSE concepts when the project context matches the concept in a strong, obvious way.

• Shrink everything to a sound byte. Make this sound byte the title of a collapse top/bottom tag. This forces the sound byte to be attractive enough to click and expand detail about the sound byte.

• Never use collapse top/bottom tags as a place holder. Use only when there is a significant amount of material (pictures, text) that would otherwise fill up an entire screen forcing users to scroll down. Always maintain a top layer that can be seen at a glance.

• Make the entire project, one page with no stubs or subpages, no links to the project root article itself, no relative links.

• Enforce "Present at any Time" to both a technical, engineering audience and the general public. So now the outline starts with "The problem description/ project description/ requirements", moves through CDIO and ends with Demo and Next Steps. The Demo has to include a link to a presentation and video of the demo.

• Instructors write the root articles. Students propose additions/modifications to the root article through user space. Students no longer modify/edit/add to general engineering project articles.

Students want to treat wikiversity as a facebook. And to a certain extent user space can be technically treated as such, but that is counter to the goal of collaboration and public information commons creation.