Status?

[pygy]

Tom, do you plan to improve TOML any further?

[parkr]

Try shooting him an email – not sure how often he checks his GitHub notifications.

[navaru]

It would be nice if the project would be passed to another maintainer, so we can improve it, pretty please!

[parkr]

/cc @mojombo

[BurntSushi]

Yes, it would indeed be great to get this project moving again. Quite a number of people have adopted TOML, and there are still a few features that would be very nice to have in the spec. If TOML is in a state of limbo, it makes it impossible for us implementors to act.

At the very least, @mojombo could share his plans so that the rest of us can act.

[pnathan]

+1

[mojombo]

I would love to find a new maintainer for TOML, to push it forward. If any of you are interested, I'd love to hear a proposal from you on what you'd do to accomplish this. Thanks!

[redhotvengeance]

👍

[jprichardson]

How about this...

Create a toml github organization. Move some of the popular toml implementations over along with the spec. Those who have created implementations, particularly the popular ones are invested and thus should join the organization. Not everyone though. Design by committee is probably worse than where we are now. Just a few core peeps.

@BurntSushi I nominate you =)

[parkr]

I second the nomination of @BurntSushi and support the creation of a toml org.

[redhotvengeance]

Agreed - a toml org sounds like a good way to go.

[88Alex]

👍

[karupanerura]

👍

[BurntSushi]

I also like the idea of a TOML organization. Docopt seems to be doing it successfully (although they lack a specification independent of an implementation).

It seems that https://github.com/toml is not available. Does anyone have any suggestions on what name we should pick instead? I thought of tomlspec, but I don't think that's appropriate since the org will also have some implementations.

Also, should the org allow for more than one implementation for a language? I'm hoping that there will always be a clear choice for each language, but perhaps if there is a legitimate conflict then we should be open to allowing more than one. Tough to say, I guess. I'm happy to wing it.

We would also need to agree on some sort of naming convention. Docopt seems to use docopt.{ext} where {ext} is the file extension commonly used in that language. This has problems when two languages share the same extension or if we allow two or more implementations for the same language.

Anyway, we don't have to decide all those things now.

[BurntSushi]

@mojombo Here's my rough proposal: focus on getting TOML to 1.0. TOML has been around for a bit of time and is being used pretty frequently in the Go community (I am not sure how much it has been adopted in other communities, although the in-development package manager for Rust is using TOML). Therefore, I would like the road to 1.0 to contain as few backwards incompatible changes as possible (even though, strictly speaking, semver would allow it). If we can do it with none, then that would be great.

Here's a more detailed proposal. In my experience, there are three primary criticisms/feature requests for TOML:

• The specification is not formal enough. I would like to remedy this by adding an EBNF to the spec. Add EBNF #199 has started this quest.
• Raw strings. People want to write regexes. I suggest we bikeshed over the syntax and get it added to the spec. I am partial to r"...".
• Multiline strings. People want this too. I'd really like to add Lua style multiline strings because they are simple and robust, but we can bikeshed over this too if others feel strongly.

Some other things that are worth mentioning:

• I would like to include toml-test in the org. Lots of people are using it (sometimes without the test runner, much to my chagrin).
• When TOML was first released, I was a pretty big proponent for adding tuples and changing arrays to be properly typed (i.e., Array of int instead of just Array). I think the ship has sailed on this and would like to move on from it unless there is some huge backlash. (This would be a backwards incompatible change, but probably wouldn't be too devastating.)

There are other feature requests on the issue tracker (different integer representations, time zones, bulk comments, scientific notation, etc.). I'm inclined to reject most of them because I believe in the design goal of TOML: keep it simple. However, I am very much open to letting the community weigh in. If we can reach a consensus on accepting some of these features, then I'd be happy with that.

[jprichardson]

Does anyone have any suggestions on what name we should pick instead?

What do you think of tomlconfig? It's not ideal though. I don't mind tomlspec either.

Also, should the org allow for more than one implementation for a language?

One implementation per language. This will alleviate confusion. The implementation should be done by someone who is familiar with their respective community so that it adheres to the community standards and best practices.

Docopt seems to use docopt.{ext} where {ext} is the file extension commonly used in that language.

This sounds good to me.

[dsoprea]

Couldn't there be a prospective problem with projects going stale or
maintainers becoming unresponsive? Unless we want those projects to be
branches off of a primary repository that is controlled by responsible
individusls, I don't know if one implementation per language is a good idea.

Thoughts?
On Jun 22, 2014 6:23 PM, "JP Richardson" notifications@github.com wrote:

Does anyone have any suggestions on what name we should pick instead?

What do you think of tomlconfig? It's not ideal though. I don't mind
tomlspec either.

Also, should the org allow for more than one implementation for a language?

One implementation per language. This will alleviate confusion. The
implementation should be done by someone who is familiar with their
respective community so that it adheres to the community standards and best
practices.

Docopt seems to use docopt.{ext} where {ext} is the file extension
commonly used in that language.

This sounds good to me.

—
Reply to this email directly or view it on GitHub
#216 (comment).

[jprichardson]

Couldn't there be a prospective problem with projects going stale or
maintainers becoming unresponsive? Unless we want those projects to be
branches off of a primary repository that is controlled by responsible
individusls, I don't know if one implementation per language is a good idea.

Of course. The idea would be not to implement anything from scratch, but to invite over one of the most popular projects for each language and the maintainer(s). If a project goes stale and as long as people find utility in it, someone will step up. i.e. things will work as they do now, except there will be one "blessed" version in the toml org.

[dsoprea]

On Jun 22, 2014 6:38 PM, "JP Richardson" notifications@github.com wrote:

Couldn't there be a prospective problem with projects going stale or
maintainers becoming unresponsive? Unless we want those projects to be
branches off of a primary repository that is controlled by responsible
individusls, I don't know if one implementation per language is a good
idea.

Of course. The idea would be not to implement anything from scratch, but
to invite over one of the most popular projects for each language and the
maintainer(s). If a project goes stale and as long as people find utility
in it, someone will step up. i.e. things will work as they do now, except
there will be one "blessed" version in the toml org.

—
Reply to this email directly or view it on GitHub.

Got it. I like it.

[pygy]

It seems that https://github.com/toml is not available. Does anyone have any suggestions on what name we should pick instead?

TOML-org? or maybe in lower case? toml-org...

IMO the latter looks better.

[redhotvengeance]

toml-lang is available, too.

[dsoprea]

+1
On Jun 22, 2014 7:11 PM, "Ian Lollar" notifications@github.com wrote:

toml-lang is available, too.

—
Reply to this email directly or view it on GitHub
#216 (comment).

[dsoprea]

toml-doc is available, too.

[karupanerura]

toml-lang++
toml-spec is available, too.

[parkr]

toml-lang feels weird to me (it doesn't quite feel like a language, the way I think of programming languages, but that's my problem), and toml-spec is too specific (the name of the spec repo). I think github.com/toml is simple and concise and meets the "goldilocks" test in terms of general vs. specific. My vote is for toml. It's also more discoverable than toml-lang if folks search toml.

[redhotvengeance]

I think the issue is that https://github.com/toml is already taken by a user account. I agree that toml-lang feels weird (I think programming languages, too), but since TOML stands for "Tom's Obvious, Minimal Language", I figured it was worth a suggestion.

[hit9]

toml-lang+1

[mojombo]

@BurntSushi Your proposal sounds great to me, and I'm keen to get TOML back on track as I still very much believe in it. Your proposal sounds good and I'd love to have you on as a maintainer.

It's unfortunate that toml is not available as an org name, and of the proposals I've seen (and can think of myself), toml-lang seems the most appropriate, as TOML is a language, even if not in the Turing-complete sense. I've registered the organization and will move this repo over there shortly. Then we can continue to move forward.

Thanks for all the enthusiasm, everyone. Let's do this thing!

[redhotvengeance]

👍

[BurntSushi]

@mojombo I'd be happy to join. :-)

I think toml-lang is probably the least bad choice available.

[mojombo]

@BurntSushi Awesome! I've added you to the Organization. Ok, next step: can you comment on existing issues or create new ones for all the main points you brought up? I'd love to hear the concrete actions you think we should take on each, and I'll make sure to respond quickly so we can reach a meeting of the minds.

I'm closing this issue and we'll continue in the various individual issues themselves.