Create Github project. #32
Comments
|
I think this is a good idea. Here is a quick summary of the state the documentation for series if people are looking for stuff on which to work (a ticked box means that I subjectively decided it was adequate and as such not a priority).
|
|
A project per series/axis/annotation? Like https://github.com/oxyplot/docs/projects/1 |
|
I also created a documentation team: https://github.com/orgs/oxyplot/teams/documentation |
|
Or should it be a org level project: https://github.com/orgs/oxyplot/projects/1 |
|
The link to the documentation team gives me a 404. I think the issues system should be fine for addressing problems with specific pages (e.g. `AreaSeries text doesn't explain feature Z"), and just having a list of severly deficient pages would be a good idea (maybe grouped by series/axes/annotations). That way anyone with some time can quickly find something useful to be doing without worrying about stepping on anybody's toes. Once the documentation is more complete, then perhaps it could be rethought, but again the issues system should work once the quality is the sole concern (useful for linking PRs, etc.; or maybe this is possible also with projects). |
|
Projects at organization level should relate to organization tasks. This means that different teams should focus on different aspects of the organization (for example, coding, testing, documentation, etc...). And on the other hand repository at project level allow to organize the tasks for repository related tasks. A good way to organize this could be to have different teams. For the moment as @objorke stated, a documentation team is fine so docs contributors can manage pull request on the docs repository. For the organization projects @objorke can organize an individual project for each type of technology that Oxyplot supports so a general view of all the progress can be seen at organization level and then assign new tasks on the roadmap to each team. About the docs repository project, a good separation of features should be provided as @VisualMelon says. The current state of Oxyplot docs provides an overview about different aspects of each oxyplot control (like Model, Controller or View) but inside them the API is detailed with Axes, Series and so on. In my opinion, each control property should contain an API specification for use (like in Object Browser in Visual Studio for example) and accompanying this one or more examples based on the difficulty so users can follow the use of the API. I will check in detail later when I have more time and provide a more detailed approach so @objorke and others can tell how they prefer to continue. |
Please add a new project to this repository so maintainers can organize tasks for each section of the documentation and provide visual feedback on which topics help is more needed.
The text was updated successfully, but these errors were encountered: