Create Github project.

[agarcialeon]

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.

[VisualMelon]

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).

• AreaSeries

  • image
  • useful text
  • code sample

• BarSeries

  • image
  • useful text
  • code sample

• BoxPlotSeries

  • image
  • useful text
  • code sample

• CandleStickSeries

  • image
  • useful text
  • code sample

• ColumnSeries

  • image
  • useful text
  • code sample (barely)

• ContourSeries

  • image
  • useful text
  • code sample: depends on ArrayBuilder, which is not ideal

• ErrorColumnSeries

  • image
  • useful text
  • code sample

• FunctionSeries

  • image
  • useful text: could do with some explanation of the constuctor
  • code sample

• HeatMapSeries

  • image
  • useful text: should be clearer what Data is
  • code sample: 2 good examples

• HighLowSeries

  • image
  • useful text
  • code sample

• HistogramSeries

  • image
  • useful text
  • code sample

• IntervalBarSeries

  • image
  • useful text
  • code sample

• LineSeries

  • image
  • useful text: more info about point markers (maybe with an example) would be nice
  • code sample

• PieSeries

  • image
  • useful text
  • code sample

• RectangleBarSeries

  • image
  • useful text
  • code sample

• ScatterErrorSeries
  (no page)

  • image
  • useful text
  • code sample: could generate an image from the exampe

• ScatterSeries

  • image
  • useful text
  • code sample: could generate an image from the exampe

• StairStepSeries

  • image
  • useful text: could be derived from LineSeries?
  • code sample

• StemSeries

  • image
  • useful text: could be derived from LineSeries?
  • code sample

• TornadoBarSeries

  • image
  • useful text
  • code sample

• TwoColorAreaSeries

  • image
  • useful text
  • code sample

• TwoColorLineSeries

  • image
  • useful text
  • code sample

• ThreeColorLineSeries
  (no page)

  • image
  • useful text
  • code sample

[objorke]

A project per series/axis/annotation? Like https://github.com/oxyplot/docs/projects/1

[objorke]

I also created a documentation team: https://github.com/orgs/oxyplot/teams/documentation

[objorke]

Or should it be a org level project: https://github.com/orgs/oxyplot/projects/1

[VisualMelon]

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).

[agarcialeon]

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.