Potential Features¶

This page is listed for archival purposes only. Please add ideas for features as New Issues.

• Core Features (merging of major features/ideas from Mach 30 meetings and posts on CSTART forums)
  • Host Projects and sub-projects (sub-projects should be first class entities with their own members, documentation, etc but parent projects should have views that merge sub-project data with parent data when desired)
  • Projects include storage for:
    • Documents such as Bill of Materials, instructions, reports, etc (probably stored in wiki-like system that includes multiple formatting filters to give content creators control over level of complexity of input vs necessary control)
    • Revision Control System to store source code for embedded systems or stand alone software projects (should be accessible directly through RCS interfaces and through web pages)
    • File storage for part models and final part drawings (still version controlled, but maybe not in the same space as the source code)
  • Users should be able to configure features used in the project
  • Project "home page" should be wiki-like as well to let project owners "sell" their projects, including posting rich media (videos, pics, etc); More like OpenRocket's home page than its sourceforge page - think public face of the project
  • Projects should also have dashboard page so members can keep up with progress (possible example) - think members' homepage for the project
  • Projects need workspace/forums to discuss design and development issues (especially for hardware) that includes linking files to comments and the main post to store the evolution of a design decision
  • Need Issue tracking, and it would be very good if it included way to directly request (and advertise) help with specific tasks/sub-tasks of the project
  • Site level homepage should highlight best hosted projects (like wikipedia does with featured articles?)
  • Projects should have a news feed (blog?)
  • donation drive module
• Newer ideas for features that need even more discussion to fully define
  • One possible engineering workflow (project features should support following all or part of the workflow as needed by the projects):
    • get/make requirements (to understand what you are going to build)
    • setup 1 or more teams/sub-projects (small scale still just 5-10 people all one team, big scale several sub-project teams)
    • create tasks that link to derived requirements to establish traceability, in multi-team scenarios, tasks should be associated with the appropriate teams/sub-projects; in single team scenario, all tasks should get associated to the main team/project when there are multiple teams, usually need a PCT (team of teams)
    • loop through below, each iteration move into more detail (lofi analysis, hifi analysis, cad parts, prototype, build, fly)
    • do work (each iteration = more detail: lo-fi analysis, hi-fi analysis, produce cad parts, prototype, build, fly/test) <–if we're generalizing
    • document (examples: procedures, BoM, drawings, parts, analyses docs, graphs, reports, meeting minutes, presentations, Requirements docs, etc)
    • review/test
    • update design
    • approve – triggers next iteration
  • Project assistance Bounty System – mash up of craigslist, sourceforge, rent-a-coder, and a solution archive. The ideas is to have a website where "customers" can post discrete analysis, report writing, peer review, hardware build, component design requests, etc. – see http://mach30.org/blogs/jrs/2009-10-22-ispcs-2009-day-1-mission-and-methods for details. This is an attempt to discretize hardware development like wiki has discretized encyclopedia writing, enabling users to hop into a project to answer a specific need.
  • Have a fans page so supporters can show their interest
  • Auto-share buttons for social network sites from project pages (to share on reddit, twitter, etc)
  • Bug/Issue tracking (duh) – should be tied to the bounty system if used?; taggable, with tags auto added for type of issue and project hierarchy (this project + parent project tags)
  • A BOM tree to visualize the structure. Also, a method to see where a part is used in other assemblies.
  • Workflow system should be extensible and allow users to share there workflows with other projects (this way we are not expected to deliver the end-all-be-all workflow, and instead, the community can discover what workflows work best in the tool); system should ship with some basic workflow(s) in this case so it has something even at release
  • Engineering file management features - Source code control for embedded systems or computer based controls, etc should be stored in one of the available Version Control Systems (VCS) such as SVN, bzr, git, etc. But engineering documents offer challenges that VCS do not handle well (very large, on order of GB files, primarily binary files). Here are some specific requirements for engineering documents. (Should investigate Enterprise CMS like Alfresco for underlying capabilities, as many of the features below are available in this class of tools.)
    • Easily manage very large files (on order of GB)
    • Easily handle binary files
    • Find a way to keep binary files (like drawings) from entering conflicted states (one option, per rpulkrabek's comment on the forums is to allow users to mark files as in use or checked out to indicate that other users should not work on those files)
    • A method to inform others, and possibly restrict others, that a certain item is currently being worked on, to avoid different design changes happening at the same time.
    • A history or RSS feed of the most recently modified items.
    • Document number generation. Possibly a running number to uniquely identify each document or part and possibly associate this number to the document. If this method is used, it's suggested that the number is also associated to a more readable description ex: ID=12345678rev01; Description=OHKLA COMBUSTION CHAMBER. Another thing to consider is variants and the numbers for that.
    • Thumbnails next to each item to quickly view what each file is (useful for CAD models).
    • A page/site to see all available attributes, such as, ID, Description, Creater, Modifier, creation date, modified date, etc.
    • Configure file storage so all files in the project (including attachments to issues/forum posts, source code VCS files, and files specifically loaded into the engineering file management system) are stored in the engineering file management system. Attachments should include link back to page where they are attached in the meta-data for the file. The idea is that all of the files wind up in a central location for easy search/backup, but are still available on the page where the context about them is located.
  • Add real-time wiki editing (like Etherpad or google docs). See list of existing tools
  • Add web based IRC client with server for hosted projects and have IRC sessions auto-logged to the project space