change ownership of this repo

[jeisner]

Should I create a "Dyna" organization? Is it then easy to transfer ownership of the repo/issues/etc.?

[nwf]

Yes to both. I think "Dyna" is taken on github already, so possibly "dynalang" or somesuch?

[timvieira]

Well, Dyna is more than just a language. So, maybe something more general than "lang" and maybe with a hyphen.

Also, while we're at it, we should have "dev" and "release" repos.

[jeisner]

Well, Dyna is more than just a language. So, maybe something more general than "lang" and maybe with a hyphen.

Suggestion? dynalang or dyna-lang dounded pretty good to me.

dyna-project is a possibility. Or dyna.org since we have that domain (is it a valid username?).

Also, while we're at it, we should have "dev" and "release" repos.

Separate repos? Really? Why not just branches?

[timvieira]

The dev branch includes development dependencies and various scripts for developers. For example we might require a developer to install a lint checker and run certain tests before pushing any changes, but a user which simply wants to build dyna from source doesn't need this.

On Wed, Jun 5, 2013 at 1:35 PM, Jason Eisner [email protected]:

Well, Dyna is more than just a language. So, maybe something more general than "lang" and maybe with a hyphen.

Suggestion? dynalang or dyna-lang dounded pretty good to me.

dyna-project is a possibility. Or dyna.org since we have that domain (is it a valid username?).

Also, while we're at it, we should have "dev" and "release" repos.

Separate repos? Really? Why not just branches?

— Reply to this email directly or view it on GitHubhttps://github.com/nwf/dyna/issues/8#issuecomment-18993906 .

[jeisner]

So does the dev repo have only those things or is there overlap?

[JoeOsborn]

As an outside observer, I'd like to vote for using branches for this! Users can checkout master, developers can checkout dev, and it should make moving changes around easier. It's also less management overhead, there's only one place to put issues, etc.

[jeisner]

Actually, before we commit too heavily to github, let's consider whether issue tracking is really good enough on gitub, or whether it is better on bitbucket or assembla or RT.

• The email-to-issue gateway on github seems to screw up the formatting. Particularly when you reply inline to a message. (Related to the fact that anything submitted by email is not parsed with markdown, nor converted to a markdown version. I'm not sure whether the reverse issue-to-email gateway does the reverse conversion, from markdown to HTML.)
• Your email is not a good mirror of the conversation on the issue tracker. When you reply on github.com instead of my email, the posting is not sent back to you. This means that you can't just search your email for a technical term if you're not sure whether it was discussed on github or on email. You have to search both.
• Unlike RT, there's no way to email directly to the issue tracker. So there is no way to cc the issue tracker on an developer email. Nor for a user to send an issue or help request by email. In RT, you could email an issue to a dedicated address, it would be properly labeled, and you'd get an autoreply.