Spec medium

[Daniel Friesen]

I know we've been using the wiki for awhile, but is this the medium
everyone prefers?
We could use the wiki, or we could use a git repo and push/pull spec
files and build a html site out of them.

Comparison:

Wiki:
- Output shows up right away
- No need to wait for someone maintaining the main site to pull from you

Git:
- Can work on specs offline
- Spec can easily be exported in a way that can be hosted anywhere and
become a downloadable spec
- Flexibility of syntax
- We could use a syntax easily compiled into spec-like specs
- Pick a syntax easier to work with
- Test scripts can be included in the repo itself and run directly from
there

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

[Kris Kowal]

On Wed, Aug 26, 2009 at 4:27 PM, Daniel
Friesen<nadir.s...@gmail.com> wrote:
>
> I know we've been using the wiki for awhile, but is this the medium
> everyone prefers?
> We could use the wiki, or we could use a git repo and push/pull spec
> files and build a html site out of them.

Thanks for this call to action. Kevin has started a github project
that will serve this purpose well. I recommend making a fork and
helping him consolidate the specs from the Wiki. I don't think we're
planning to deprecate the Wiki though; between it and the mailing list
archive, we can have both a version controlled specification and more
flexible records for how decisions were made and why.

http://github.com/dangoor/jshq/tree/master

Kris Kowal

[Wes Garland]

Googlecode publishes it's wiki as mercurial repo.

Now how's THAT for a compromise?

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Daniel Friesen]

Hmm, interesting idea.
Although it does lose a lot of flexibility:

Mozilla Wiki:
- Anyone can update the central view
- Easy preview
- Edit online

Git:
- Flexible syntax
- Offline
- Semi-easy preview (you can build it locally)
- Syntax flexibility

Googlecode wiki:
- Anyone with commit to the repo can update the central view
- Offline
- Edit online

Personally, when I was thinking syntax, I was thinking of taking one of
the existing Markdown or Creole libraries already written in JavaScript
and using them.
I honestly dislike googlecode's wiki syntax. Every time I tried to write
some api stuff on googlecode the syntax always got in my way.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

[Kris Kowal]

On Wed, Aug 26, 2009 at 4:49 PM, Daniel
Friesen<nadir.s...@gmail.com> wrote:
> Personally, when I was thinking syntax, I was thinking of taking one of
> the existing Markdown or Creole libraries already written in JavaScript
> and using them.
> I honestly dislike googlecode's wiki syntax. Every time I tried to write
> some api stuff on googlecode the syntax always got in my way.

The syntax that Kevin has in JSHQ is somewhat compatible with the
syntax on the current wiki. It uses a bidirectional wiki markup
module called Wiky, which I've already ported to CommonJS né ServerJS.
The parser still needs some work before it's 100% compatible.

http://github.com/kriskowal/wiky/tree/master

I'm not set on the present wiki language either, but using a different
markup language will slow things down.

Kris Kowal

[Joe Developer]

http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki

Or start hacking on google wave ;)

[Kevin Dangoor]

On Wed, Aug 26, 2009 at 7:27 PM, Daniel Friesen <nadir.s...@gmail.com> wrote:

Git:
- Can work on specs offline
- Spec can easily be exported in a way that can be hosted anywhere and
become a downloadable spec
- Flexibility of syntax
 - We could use a syntax easily compiled into spec-like specs
 - Pick a syntax easier to work with
- Test scripts can be included in the repo itself and run directly from
there

I could imagine a workflow something like this:

- start something completely new on the wiki
- kick around the alternate ideas
- once a general direction is agreed upon, move the spec-in-progress to git
- work out the details/tests in git

The wiki does seem like a low-barrier way to dive in and work through alternatives. I'm not opposed to all-git, however.

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

[Tom Robinson]

On Aug 26, 2009, at 7:39 PM, Kevin Dangoor wrote:

On Wed, Aug 26, 2009 at 7:27 PM, Daniel Friesen <nadir.s...@gmail.com> wrote:

Git:
- Can work on specs offline
- Spec can easily be exported in a way that can be hosted anywhere and
become a downloadable spec
- Flexibility of syntax
 - We could use a syntax easily compiled into spec-like specs
 - Pick a syntax easier to work with
- Test scripts can be included in the repo itself and run directly from
there

I could imagine a workflow something like this:

- start something completely new on the wiki
- kick around the alternate ideas
- once a general direction is agreed upon, move the spec-in-progress to git
- work out the details/tests in git

The wiki does seem like a low-barrier way to dive in and work through alternatives. I'm not opposed to all-git, however.

Kevin

+1 but also not opposed to all git.

[Daniel Friesen]

Where do people normally do their development?

I do a good majority of my work in-transit where I have no connection
(Almost an hour travel time between home and work, each way).

The spec being online means during that time I can't do much work
writing something. And having Binary/C online has hindered my
implementation of it.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

[Joe Developer]

I am not quite sure why you don't try out fossil, if not for SCM then for the fact that it can act as a light weight distributed wiki.

On the other hand you could have both the existing wiki and git support with the use of git-hooks.

[Aristid Breitkreuz]

Daniel Friesen schrieb:

> The spec being online means during that time I can't do much work
> writing something. And having Binary/C online has hindered my
> implementation of it.
>

+1 on that (if for slightly different reasons, i.e. my paranoia about
central servers)

So we should go for all-git, IMHO.

Aristid

[Daniel Friesen]

Ok, looks like we're sticking with Wiki+jshq git repo

On the topic of wiki. Any reason to stick with the mozilla wiki?
Has anyone made an attempt at finding someone to move ServerJS to CommonJS?

Perhaps switching over to Wikia would be a good idea...

Pros:
- Externally hosted (Wikia's reliability is quite strong)
- Great pagerank (Tom Robinson made a note in #commonjs about our issues
with the googlerank on commonjs, things on Wikia normally can get pretty
high, and in the case of our name the issue is that MediaWiki
installations like Wikia and Wikipedia have a Common.js that destroys
the rank, this should probably counter that)
- Control; The ability to move pages without asking someone else. Also
Wikia is community oriented, so we don't have to worry about losing
people with flags since we can just ask for a flag or two on anyone.
- Wikia is quite helpful with extensions and whatnot. javascript.wikia
(Inactive) has SyntaxHighlight_GeSHi installed. It would be a simple
request to have it enabled on commonjs.wikia so we can have highlighting
on the chunks of code we put in the spec (It'll probably be enabled
before anyone even reads this).
- Reliable dumps; http://commonjs.wikia.com/wiki/Special:Statistics
(dumps are listed, dumped weekly, and can be requested quicker by a
button press)
-- Technically with a little xml reading and that wiky script we could
take the spec right out of the wiki dumps.
-- Heck, a little xsl hacking, javascript, and wiky and we could
probably turn a xml wiki dump into a standalone browseable spec/wiki.
Cons:
- Wikia does use advertising for their revenue, they are a tiny bit
obtrusive in some cases, it depends on your pov I suppose.

To take a look at how it would work out I created the wiki and imported
the old pages:
http://commonjs.wikia.com/

What does everyone think? Move to that wiki, or stay at mozilla wiki?

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

[Kevin Dangoor]

On Thu, Sep 3, 2009 at 4:52 AM, Daniel Friesen <nadir.s...@gmail.com> wrote:

Ok, looks like we're sticking with Wiki+jshq git repo

On the topic of wiki. Any reason to stick with the mozilla wiki?
Has anyone made an attempt at finding someone to move ServerJS to CommonJS?

No reason, and no.
 

Perhaps switching over to Wikia would be a good idea...

Pros:
- Externally hosted (Wikia's reliability is quite strong)
- Great pagerank (Tom Robinson made a note in #commonjs about our issues
with the googlerank on commonjs, things on Wikia normally can get pretty
high, and in the case of our name the issue is that MediaWiki
installations like Wikia and Wikipedia have a Common.js that destroys
the rank, this should probably counter that)

I wouldn't worry about pagerank. I'm pretty sure that we'll very quickly rise to the top of "commonjs" searches. I haven't started promoting the new name yet (going to get commonjs.org in better shape before I do).

I stalled a bit because of some other things that came up outside of geekery, but I expect to be back on the jshq site within a few days.
 

- Control; The ability to move pages without asking someone else. Also
Wikia is community oriented, so we don't have to worry about losing
people with flags since we can just ask for a flag or two on anyone.

As a Mozilla employee, I may be able to get permissions to make moves and whatnot.

That said, the biggest drawback I've seen to wiki.mozilla.org is that it's *slow* to save. Really annoying. If Wikia fixes that, then a switch sounds nice to me.
 

- Wikia is quite helpful with extensions and whatnot. javascript.wikia
(Inactive) has SyntaxHighlight_GeSHi installed. It would be a simple
request to have it enabled on commonjs.wikia so we can have highlighting
on the chunks of code we put in the spec (It'll probably be enabled
before anyone even reads this).
- Reliable dumps; http://commonjs.wikia.com/wiki/Special:Statistics
(dumps are listed, dumped weekly, and can be requested quicker by a
button press)
-- Technically with a little xml reading and that wiky script we could
take the spec right out of the wiki dumps.

-- Heck, a little xsl hacking, javascript, and wiky and we could
probably turn a xml wiki dump into a standalone browseable spec/wiki.

I'm not inclined to do this. I do still think it's better to move the specs that have gone beyond the initial exploration into git and a separate, more static site.

Being able to do dumps is still a nice thing, though.
 

Cons:
- Wikia does use advertising for their revenue, they are a tiny bit
obtrusive in some cases, it depends on your pov I suppose.

This doesn't bother me. Again, I'm looking at the wiki as being the place for proposals that can be all over the map, with a move to a real repo and site after the proposals are done.
 

To take a look at how it would work out I created the wiki and imported
the old pages:
http://commonjs.wikia.com/

What does everyone think? Move to that wiki, or stay at mozilla wiki?

I'm fine with moving the wiki part of the process over to wikia, if edits are faster :)

Thanks for importing the pages there!

Kevin

[Daniel Friesen]

Kevin Dangoor wrote:
> On Thu, Sep 3, 2009 at 4:52 AM, Daniel Friesen
> <nadir.s...@gmail.com <mailto:nadir.s...@gmail.com>> wrote:
>
>
> Ok, looks like we're sticking with Wiki+jshq git repo
>
> On the topic of wiki. Any reason to stick with the mozilla wiki?
> Has anyone made an attempt at finding someone to move ServerJS to
> CommonJS?
>
>
> No reason, and no.
>
>
> Perhaps switching over to Wikia would be a good idea...
>
> Pros:
> - Externally hosted (Wikia's reliability is quite strong)
> - Great pagerank (Tom Robinson made a note in #commonjs about our
> issues
> with the googlerank on commonjs, things on Wikia normally can get
> pretty
> high, and in the case of our name the issue is that MediaWiki
> installations like Wikia and Wikipedia have a Common.js that destroys
> the rank, this should probably counter that)
>
>
> I wouldn't worry about pagerank. I'm pretty sure that we'll very
> quickly rise to the top of "commonjs" searches. I haven't started
> promoting the new name yet (going to get commonjs.org

> <http://commonjs.org> in better shape before I do).

>
> I stalled a bit because of some other things that came up outside of
> geekery, but I expect to be back on the jshq site within a few days.

If we can get something that works server-side (probably with narwhal),
would you mind if we switched over to compiling pages rather than using
that client-side js? As fancy as it is using js like that makes loading
of the actual page slower, means we have to have js in order to navigate
the site, google can't index the site properly, and every pageview
requires 2 http requests just to load the actual content (the actual
page + contentwrapper).

>
>
> - Control; The ability to move pages without asking someone else. Also
> Wikia is community oriented, so we don't have to worry about losing
> people with flags since we can just ask for a flag or two on anyone.
>
>
> As a Mozilla employee, I may be able to get permissions to make moves
> and whatnot.
>
> That said, the biggest drawback I've seen to wiki.mozilla.org

> <http://wiki.mozilla.org> is that it's *slow* to save. Really

> annoying. If Wikia fixes that, then a switch sounds nice to me.

I see what you mean now that I make a sandbox edit. Ya, there's no edit
lag on Wikia like there is on the mozilla wiki, edits save basically as
fast as any pageview.
(Note that I'm working with their rich text editor disabled; If that's
causes problems we can have it disabled; The rich text editor itself
though is better than the broken one on MDC fwiw)

>
>
> - Wikia is quite helpful with extensions and whatnot. javascript.wikia
> (Inactive) has SyntaxHighlight_GeSHi installed. It would be a simple
> request to have it enabled on commonjs.wikia so we can have
> highlighting
> on the chunks of code we put in the spec (It'll probably be enabled
> before anyone even reads this).
> - Reliable dumps; http://commonjs.wikia.com/wiki/Special:Statistics
> (dumps are listed, dumped weekly, and can be requested quicker by a
> button press)
> -- Technically with a little xml reading and that wiky script we could
> take the spec right out of the wiki dumps.
>
> -- Heck, a little xsl hacking, javascript, and wiky and we could
> probably turn a xml wiki dump into a standalone browseable spec/wiki.
>
>
> I'm not inclined to do this. I do still think it's better to move the
> specs that have gone beyond the initial exploration into git and a
> separate, more static site.
>
> Being able to do dumps is still a nice thing, though.

At the least we could probably have a cron job put wiki archives on jshq
as reference and backup.

>
>
> Cons:
> - Wikia does use advertising for their revenue, they are a tiny bit
> obtrusive in some cases, it depends on your pov I suppose.
>
>
> This doesn't bother me. Again, I'm looking at the wiki as being the
> place for proposals that can be all over the map, with a move to a
> real repo and site after the proposals are done.
>
>
> To take a look at how it would work out I created the wiki and
> imported
> the old pages:
> http://commonjs.wikia.com/
>
> What does everyone think? Move to that wiki, or stay at mozilla wiki?
>
>
> I'm fine with moving the wiki part of the process over to wikia, if
> edits are faster :)
>
> Thanks for importing the pages there!
>
> Kevin

Ok, if others feel similarly about moving just put an account on Wikia
(ideally with the same username as the one you had on mozilla so that
your edits get attributed to you) and tell me what it is. I think I'm
probably just going to give every major contributor to discussions here
the permission flags (unless we have actual project heads that I have no
clue about). Poke me if I got it wrong but (Kevin Dangoor, Kris Kowal,
Tom Robinson, Wes Garland, Ash Berlin) are the ones that stand out to me?

> --
> Kevin Dangoor
>
> work: http://labs.mozilla.com/

> email: k...@blazingthings.com <mailto:k...@blazingthings.com>
> blog: http://www.BlueSkyOnMars.com

[Kevin Dangoor]

On Thu, Sep 3, 2009 at 1:34 PM, Daniel Friesen <nadir.s...@gmail.com> wrote:

If we can get something that works server-side (probably with narwhal),
would you mind if we switched over to compiling pages rather than using
that client-side js? As fancy as it is using js like that makes loading
of the actual page slower, means we have to have js in order to navigate
the site, google can't index the site properly, and every pageview
requires 2 http requests just to load the actual content (the actual
page + contentwrapper).

Assuming I can make the experience just fine, I'd prefer to leave it client side. I'd like to be able to use that as a test case for editing/previewing in a hosted Bespin.

My intention all along has been to run the JS through a compressor and to compile the contentwrapper directly into the JS. It's already pretty fast and will be even faster after those steps.

Also, Google will actually work just fine since the content of the page is all there... it's just the content that's missing. (In the case of wiki markup pages, I'm not sure what google will think of the URLs appearing there...)

If people are really bothered by the client-side rendering, then I think the next alternative (and a very easy one at that) is a Narwhal-based script that renders the site. Ok, if others feel similarly about moving just put an account on Wikia

(ideally with the same username as the one you had on mozilla so that
your edits get attributed to you) and tell me what it is. I think I'm
probably just going to give every major contributor to discussions here
the permission flags (unless we have actual project heads that I have no
clue about). Poke me if I got it wrong but (Kevin Dangoor, Kris Kowal,
Tom Robinson, Wes Garland, Ash Berlin) are the ones that stand out to me?

I've just registered as kdangoor (which is my name on the mozilla wiki).

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com

blog: http://www.BlueSkyOnMars.com

[Daniel Friesen]

btw, I already have http://serverjs.wikia.com redirecting to
http://commonjs.wikia.com and the syntax highlighting extension is
installed.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]