On Saturday, 18 June 2016 at 20:04:50 UTC, Walter Bright wrote:
> Starting a new thread with this, as requested. There are things here for all skill levels and time commitments.
>
> 3. use -cov to improve code coverage of Phobos unittests
>
> 4. make sure every function in Phobos has an example
>
> 5. make sure every function in Phobos has Params: and Returns: sections
> http://www.digitalmars.com/d/archives/digitalmars/D/Phobos_Documentation_-_call_to_action_258777.html

Maybe someone would like to go a step meta and look into automatically tracking and checking things first? Here is what autotester (or some other tool) could do:

* Check for a lower bound of coverage, so we never regress.

* Check documentation for Example, Params:, Returns:

* Check for broken links

By tracking I think: Count the stuff above and plot over time. Somebody did this for the number of pull requests, for example. This in itself does not fix anything, but it motivates. "Measure it and it will improve" –Jack Welch

On Monday, 20 June 2016 at 07:48:49 UTC, Andrea Fontana wrote:
> On Saturday, 18 June 2016 at 20:04:50 UTC, Walter Bright wrote:
>
>> 6. replace std.xml with something we can be proud of that is second to none in performance (Robert burner Schadek is mentoring on this https://github.com/lodo1995/experimental.xml)
>
> I hope it will support html and xpath too.
>
> Andrea

The low-level parser is explicitly written to support any format which resembles XML, and will have no problem handling HTML. Regarding higher level APIs: with validations turned on, HTML would surely be rejected (it breaks many XML well-formedness constraints); with validations turned off, it may or may not work, because higher level APIs implicitly assume that their input is well-formed.

As for XPath, I probably won't have time to work on it during GSoC, but if everything goes well I may work on it after the end of the project.

Lodovico Giaretta

https://lexi-lambda.github.io/blog/2016/06/12/four-months-with-haskell/#documentation-is-nearly-worthless - found this on reddit, criticizes haskell docs and praises racket docs:
> they are so effective because of how the prose explains what each function does, when to use it, why you’d use it, and why you wouldn’t use it.