One of the things we should add to the new README is a tip pointing people toward the DDOC = macro in std.ddoc.

That's the skeleton html for the website and is pretty plain.

On Sun, Jul 14, 2013 at 2:37 PM, Walter Bright <newshound2@digitalmars.com>wrote:

>
> I agree with your three points. I'll add that anyone can do a pull request to address any/all of these.
>

How can someone send a pull request to address the long latency of responding to pull requests? The other issues I pointed out are blocked on that one, because until that is addressed, there's no point in sending PRs. My free time is both limited and precious to me and I'm sure the free time of others is precious to them as well. As an outside contributor, if I see that contributions are not valued highly (as evidenced by the response time; I'm sorry but that's just the way it works) I don't feel motivated to contribute.

I give freely of my own time, make changes, send a pull request and then wait months for a maintainer to so much as glance in its direction. You can see the problem here.

As a project maintainer, if you want others to contribute to your project you need to make contributing utterly frictionless.

On 7/14/2013 2:59 PM, Val Markovic wrote:
> How can someone send a pull request to address the long latency of responding to
> pull requests?

There are 13 open PRs, and about 335 pulled ones.

While we can and must do better, I don't think the situation is as dire as you suggest.

There are currently 12 team members with pull privileges on the dlang.org repo. If you feel a particular PR is being overlooked, or your work is blocked by it, you can ping them.

We also tend to promote prolific contributors into being team members, so they become part of the problem :-)

You can also post bug reports for the website on bugzilla:

http://d.puremagic.com/issues/

and select "websites" under "Component", and assign the severity as you see fit.

On Sun, Jul 14, 2013 at 3:34 PM, Walter Bright <newshound2@digitalmars.com>wrote:

> While we can and must do better, I don't think the situation is as dire as you suggest.
>

I think it's more dire than you realize, but I could be wrong. Here are a few links to pull requests on dlang.org that seem to need love from the maintainers.

No updates from upstream for:

3 months: https://github.com/D-Programming-Language/dlang.org/pull/311 4 months: https://github.com/D-Programming-Language/dlang.org/pull/304 4 months: https://github.com/D-Programming-Language/dlang.org/pull/292 4 months: https://github.com/D-Programming-Language/dlang.org/pull/267

I've created and led several successful open source projects and I've contributed to many more. The rule of thumb I've observed is that "a few days" of response latency is fine, ~5 days is plenty and anything more than a week is too long and sends the wrong signal. I can't say I've always observed this rule of thumb myself (sometimes I forget or slip up), but it's a bar I try to meet.

I appreciate your agreement that the community can and must do better.

On 7/14/13 5:20 PM, Walter Bright wrote:
> On 7/14/2013 2:30 AM, Jacob Carlborg wrote:
>> I think it madness that the site is written in Ddoc.
>
> Different, sure. Madness - why?

If you look at for example this file:

https://github.com/D-Programming-Language/dlang.org/blob/master/lex.dd

All I see is HTML with a different syntax. You can achieve the same using html tags (<h4> instead of $(H4)) and div ids or classes, then applying css rules.

If somebody wants to contribute, it's sure easy to understand HTML. But understanding DDoc requires more knowledge, so less chance of receiving contributions.

But I think it's ok to do the website... for dog-fooding :-)

On 7/14/2013 7:19 PM, Ary Borenszweig wrote:
> On 7/14/13 5:20 PM, Walter Bright wrote:
>> On 7/14/2013 2:30 AM, Jacob Carlborg wrote:
>>> I think it madness that the site is written in Ddoc.
>>
>> Different, sure. Madness - why?
>
> If you look at for example this file:
>
> https://github.com/D-Programming-Language/dlang.org/blob/master/lex.dd
>
> All I see is HTML with a different syntax. You can achieve the same using html
> tags (<h4> instead of $(H4)) and div ids or classes, then applying css rules.

HTML doesn't work for other kinds of output that is supported by the makefiles - ebook, pdf, etc.

I wrote the original Digital Mars web site in plain html. That's what motivated me to invent Ddoc. I'm at least twice as productive in Ddoc, maybe even 4 times. For example, if I want to change the copyright notice, I can:

1. edit hundreds of files

   -- or --

2. edit a Ddoc macro

It's no contest.

> If somebody wants to contribute, it's sure easy to understand HTML. But
> understanding DDoc requires more knowledge, so less chance of receiving
> contributions.

Ddoc isn't any harder than any of the innumerable markup languages out there, like mediawiki.

On 2013-07-15 05:22, Walter Bright wrote:

> HTML doesn't work for other kinds of output that is supported by the
> makefiles - ebook, pdf, etc.

I thought the PDF was generated from the HTML output.

> I wrote the original Digital Mars web site in plain html. That's what
> motivated me to invent Ddoc. I'm at least twice as productive in Ddoc,
> maybe even 4 times.

Come on. That's like say "I'm more productive using C than writing in machine code directly". Try comparing with PHP, Python, Ruby on Rails, D or any other language. Plain HTML just sucks.

> For example, if I want to change the copyright
> notice, I can:
>
> 1. edit hundreds of files
>
>     -- or --
>
> 2. edit a Ddoc macro

You can do that with any other language or template system that support templates or similar.

> Ddoc isn't any harder than any of the innumerable markup languages out
> there, like mediawiki.

I was more thinking of a proper language, as mentioned above.

-- 
/Jacob Carlborg

On 2013-07-14 22:20, Walter Bright wrote:

> Different, sure. Madness - why?

"Madness" might be stretching it. You're making it unnecessary hard for someone not familiar with how the D website is structured. Example, I added a couple of new files to Phobos (std.serialization), which it properly generates the HTML files for. But why don't them show up in the left side menu?

-- 
/Jacob Carlborg

On 2013-07-15 08:40, Jacob Carlborg wrote:

> "Madness" might be stretching it. You're making it unnecessary hard for
> someone not familiar with how the D website is structured. Example, I
> added a couple of new files to Phobos (std.serialization), which it
> properly generates the HTML files for. But why don't them show up in the
> left side menu?

Another example. How do I create a macro that takes a string like "std.algorithm.find" and create a link to the std.algorithm page and the "find" function?

-- 
/Jacob Carlborg

On 2013-07-14 23:18, Val Markovic wrote:

> 3. Ruby on Rails (or Django or any other web framework that dynamically
> builds a server response) would be a terrible choice for a static
> website. It would be nothing but overhead for no benefit. Nothing on
> dlang.org <http://dlang.org> is dynamically generated, nothing talks to
> a database (nor should it). The site can and should be generated from
> some simple markup language. The end result should be HTML, CSS, JS and
> image files that are then just served by the simplest of servers.

Why not? We're limiting our self here. Someone talked about adding comments to the documentation, like PHP has. Or do you want to use a database that JavaScript can talk to directly, to avoid server side scripts?

-- 
/Jacob Carlborg