The way I see it, the progress bar aka roadmap should be redesigned, not only aesthetically, but content-wise as to truly reflect the project's position.

This could be done as follows:

• List all accomplished tasks and its duration.
  • Sub-tasks should be stated as dependencies for the completion of said task
  • Each task/sub-task should be owned by a department or person..as in who did it(debatable)
• Categorize task.
  • Either by: * R&D * PR * Production * ETC....
  • Or by priority; seeing as how some tasks were dependent on others.
• List proceedings without mentioning set dates or deadlines
• Issues should be listed in every task header and independently as to elaborate further on its closure or resolution.
• [EDIT 00:26-11/08/2016] We should also add risks
  We could use milestones to keep track of closed tasks. It will give us and visitors a sense of accomplishment. I am reluctant to suggests the use of Gantt Chart as a visual representation, seeing as how it will be way too crowded.

It seems that my general idea of simplicity failed, as you can see from the mockup below. I decided to use Xmind for visualization as oppose to Gantt. The problem with Gantt is that is relies heavily on duration, and seeing as how some tasks(Feasibility Study for example) dates back to 2013. A standard Gantt will just show an long lines. Nonetheless, the mockup below has it's advantages.

• Html based - See ma.tc for a demo
• Easy work environment through Xmind
• No due dates of timelines

Disadvantages:

• Manual entry which translates to "Hard to manage/update"
• Might seem as a bit off..as it doesn't really convey the message of "Things are actually happening here" concisely
• Hard to read

On a side-note; if regular updates; i mean even minute changes is what is desired, then I suggest opening a phabricator instance to the public( https://www.phacility.com/ ) . As usual, up for discussion.

---

UPDATED VIEW

In ops#9 (comment 7578) I distinguish ARTICLE and NEWSLETTER. But in Pelican parlance, the technical correspondence is different.

In order to clarify, here's the right correspondence:

• ARTICLE in my comment is a PAGE in Pelican.
• NEWSLETTER in my comment is an ARTICLE in Pelican.

(Pelican is the Python-based static site generator we're using...)

That said, the correspondence is not entirely true, since Pelican makes the difference between an updated article ("news") and a thematic page that we don't want to make: we want both types to appear on the homepage when they're updated. This might require playing around the semantic definitions of Pelican.

Pasting from ops#9 (comment 7594) :

#9 (closed) (comment 7578) looks good

ACK

given you actually adhere to those rules :-)

the post itself might even make a nice uBlog or "article"

wondering how we break out such issues as a separate issue, instead of keeping it in a "meeting xxxx-yy-zz" melange of unasorted stuff. Maybe as a general rule: always create a new topic as soon as some comment to a meeting topic point gets added? What I said: gitlab maybe provides means to manage stuff, but it doesn't enforce it. Plus we (I at least) need education on how to correctly use this tool

@joerg_rw I think each point should be an issue, then "Meeting issues" can become a milestone. Therefore I propose to make "Newsletter Issues" milestones, and add news items as issues in that milestone. This way we can set a deadline on the newsletter (milestone feature), move news items to the next milestone easily (builtin drag-n-drop), follow progress, edit the first issue post for the final wording, and use comments in the issue to discuss the wording (as we've been doing with articles).

As for the text version of the roadmap. I decided to go with a more Objective oriented approach. Note Completeness % is calculated by completed_tasks/all_tasks_within_action

--BEGIN--

NEO900

• Objective: Create an open and secure mobile platform.

• Success Criteria: The successful reception of the concept by means of Proof-Of-Work in the field.

• Actions:

• R&D

  • Objective: Study and design various electronic/shell aspects of the concept.
  • Success Criteria: A fully tested Prototype that adheres to XY security and Blah standards.
  • Actions: * Feasibility Study | C [01/01/2013] * Infrared system design | C [01/02/2016] * NFC Subsystem | C [01/04/2016] * Hackerbus | C [04/03/2015] * SIM Switch System | C [06/08/2015] * IO Expanders | C [03/04/2014] * Modem Switch * Spacers Design * PCB Testing * Blah Schematics * Prototype Development
  • Completeness %: 54%
  • Notes: Something relevant
  • Driver: Joerg & Wpwrak

• PR & Webmaster

  • Objective: Communicate transparently with the community and safe guard web presence.
  • Success Criteria: Establish fluid communications with supporters and receive A+ security rating.
  • Actions: * Server Migration | C [01/08/2016] * Newsletter Release | Once-A-Month(Check /news for releases) * Electronics engineering Git repository | C [01/08/2016]
  • Completeness %: 66%
  • Notes: Something relevant
  • Driver: Hellekin & Dos & Joerg

• Production & Shipping

  • Objective: Assemble units and ship.
  • Success Criteria: Fulfill all Neo900 orders.
  • Actions: * Finalize N900 Sourcing * Manufacture PCB * Platform assembly * Full platform Test * Ship
  • Completeness %: 0%
  • Notes: Delay expected due to dependencies
  • Driver: Joerg & XY Company(PCB)

• Fundraising

  • Objective: Raise XYK Euros in funds.
  • Success Criteria: Reach 100% of raised funds by Aug 2016
  • Actions: * Open Webstore for pre-orders | C [02/06/2016] * Seek Donations * Blah * Blah Blah * Blah Blah Blah
  • Completeness %: 20%
  • Notes: Blah Blah Blah

• Driver: Team

• Completeness %: 37%

• Notes: Blah Blah Blah

• Driver: Team

--EOF--