Great that you have funding for a new editor. Really excited to see better editors. I would caution exceptionally strongly against wedding it to the old DocuBricks XML standard. It is inflexible, hard to diff, and behaves badly in a Git repository.
The best way we can all be compatible is to have a similar underlying data model. @bhaugen and @jarancio have both talked to me about the importance of defining the data model that underlies GitBuilding.
In GitBuilding we have focussed very much on how to minimise data duplication and increase the flexibility to document more and more complex projects. We had to reorganise things a few times on the way as we found limitations to the approach. We iterated towards our current semantic data structure.
The value of GitBuilding is not the software, the software is bodged together by me, and the editor (as you have noticed) is beyond basic. The work we poured into it over the last 3-4 years has been on how to make the data flexible. Please, let us talk about the underlying structure and how to make that work together. If we get this right then building some a WYSIWYG editor is just software engineering we can outsource.
We need this community to get behind a standardised format. I have been looking for funding to get more people into a room (or a virtual room) to discuss this, so that we can make sure everyone’s needs are catered for, and so we can make the format extensible for manufacturing, quality control, etc.
Yes, let’s set up an open video call in March, when my new project team members start to discuss a way forward.
XML is just a basic data format, not for Git, and can be left out without problems. What’s valuable from our years long iterations in the DocuBricks project is not the data format, but the nomenclature (https://www.docubricks.org/software.jsp) and basic modularity concept. Let’s see what makes sense to make compatible and where each person sticks their favourite tools and languages (I know you have very strong views there, Julian ). Us unites the aim to have a modular extensible and easy to use (from each of our perspectives) documentation tool that should use the cool Git version control capability of GitBuilding and that can be copied into any repository/blog.
Hey, we found a new team member here in Chile to work on an interface for the GitBuilding documentation software. It would be great to have a joined call early March when he starts to discuss ways forwards!
Thanks @kaspar for the open manual link!
Bucknell University uses Dozuki, @scientist, for much of their maker work.
The Bucknell SpeakerBox Assembly is how I reinforce much of the introductory skills content in my maker course, before they are ready for Open Source Hardware projects. Speaker Assembly 2019 - Bucknell Makers (dozuki.com)
Dozuki did make a $50 per month deal with me to experiment with similar training displays. I used it for several months, but my university wasn’t ready to commit to a full software license.
In Gitbuilding we have implemented a completely separate data format. We do have an open issue to implement oManual import/export, where import seems like the more feasible one since Gitbuilding is much less strict about structure than oManual.
). Us unites the aim to have a modular extensible and easy to use (from each of our perspectives) documentation tool that should use the cool Git version control capability of GitBuilding and that can be copied into any repository/blog.
