Re: Documenting best practices and the state of ToolChain guidelines using CPAN and POD

[email protected] ("Philippe Bruhat (BooK)")
Newsgroups perl.cpan.workers
Message-ID <[email protected]>
On Fri, May 08, 2015 at 11:39:59AM +1200, Kent Fredric wrote:
> 
> Ok, this is an OK starting point for me. Its not *my* ideal because there's
> of course the audience who have PAUSE keys and not github accounts ( and
> don't want them ), but thats more a side note at this moment ( And was
> inherently a likely contribution limitation to my suggestion w/ other
> repos, just not their own )

No one needs to register anywhere to contribute to a git repository:
if they want to go the hard route, git format-patch and git send-email
are their friends.

> I like that its got aggregation options, and that it can pull from
> different locations.
> 
> So can we talk about layout and authorship concerns?

The following represents what cpan.io does now. It was put together
in half a day. It's open source, and I welcome pull requests. So it's
flexible. We can modify it to suit whatever need we have.

> 1. How often do aggregated repositories get sourced?

every hour.

> 2. How easy is it to stipulate adding more repositories?

Send a pull request for updating cpanio.yml to http://github.com/book/CPANio

> 3. What mechanism is there for restricting what an automated update pulls

I've put a few restrictions in the form of 'include' (defaults to *),
'exclude' (defaults to nothing), and recurse (defaults to don't).

> so that only "finalised" docs are published, and not drafts?

it can pull from a named branch, so you could have a "final" branch
for those documents.

> 4. How exactly are the sourced documents layed out

Simple template with basic HTML around.

For now, only markdown format is supported, but I intend to support
additional formats as needed.

> 5. How are we going to optimise our policy layout so its clear which
> policies are newest

Docs are listed in the order the repositories are listed in the yaml file,
and then by creation date.

> 6. How are we going to optimise our policy layout so its clear when a
> policy was last modified

The bottom of each document has a "Last modified by" line, based on the
last commit on that file.

> 7. How are we going to optimise our policy layout so its clear from a users
> perspective what  changes have happened recently in any policy.
> 
> Point 5 is easily solved by the numerical sequencing we covered earlier.
> 
> Points 6 and 7 are hard, but are presently satisfied by metacpan.

I suppose we could have the date in the table of content, or even
a "last modified" page. Generating a RSS file is also possible.

> Keep in mind I'm trying for a solution here that we can apply to cpan.io
> that covers project policies like Moose/DBIC/Catalyst as well as author
> policies like Author::RIBASUSHI.

I'm not sure author policies would fit in CPAN.io, but I guess we need
to see how this evolves.

> With regards to the latter half, we may be interested in a system where an
> author can ship to both CPAN and integrate with the cpan.io website, or do
> only one of the two, using the same codebase.

For now, the authors had nothing special to do to have their documents
supported on CPAN.io. I would be nice if it could stay this way.

I tested with toolchain-site to show up the Oslo and Lancaster consensus
documents, and they showed up just fine.

I don't foresee any special difficulty in publishing a set of pod
documents living on CPAN.

> Or they may wish to simply host their policies on their own somewhere.

That's probably what most people do at the moment.

> Either way, we should pave a path for interop to make it easy to do the
> right thing.
> 
> 
> I would probably also consider a JSON/YAML file being listed in each policy
> root that acheives some of the above concerns:
>   - associates policies with tags
>   - define desired policy presentation order
>   - define visibility of policies at the top level ( ie: so that deprecated
> policies don't list on the main lists )
> 
> etc.

Good idea! This special config file should be optional, though.

-- 
 Philippe Bruhat (BooK)

 Sometimes only by losing the battle can you win the war.
                                   (Moral from Groo The Wanderer #117 (Epic))
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.