This project was created by engineers which were motivated by the idea to describe the graphs of the main knowledge/skills of different types of engineers which in turn provides a way to develop these graphs by the community and by the approach which engineers prefer.
In development teams with official mentoring and level assessments it's important to have a shared understanding of the process. To handle it, teams usually create knowledge roadmaps if form of spreadsheet with subjects and skills for a particular stack, and store it in a cloud. The issue here is that every developer, regardless of the programming language he uses, has to cover common subject areas, such as computer science, databases, etc. For 10+ stacks changing one skill in a common subject area means you have to manually edit 10+ spreadsheets. That prompts loss of uniformity of content and structure. For developers, who are used to a well-established change process, it discourages further collaboration and improvement of the roadmaps.
For developers, Skill Matrix is a module that allows to create and collaborate on knowledge roadmaps. A roadmap is compiled from several subject areas, which are described in separate XML files. This allows to reuse components and to populate a change made in one subject into all roadmaps using it. Skill Matrix allows to compile a roadmap in a XML syntax, visualize it in form of graph, and convert it to Markdown file and spreadsheet, thus covering all desirable representation formats. As a git project, it establishes an adaptable process for change and collaboration.
For future development of the project the following options are considered: Elaboration on roadmaps structure, adding learning materials. Creating a tool to check errors in files, such as invalid links in materials files. Creating roadmaps for other stacks: Python, Ruby, Java Script, .NET C#, Scala, etc. Adding sets of interview questions for subjects and skills (similar to materials).
Before you continue, ensure you meet the following requirements:
All changes should be developed in your own feature branch and merge throw the merge request. Also, you should update the project each time you change any XML file by: