Thoughts about ex_doc

[Peter Minten]

Hi all,

I've been thinking about how ex_doc could be improved to provide better
documentation. This is a bit of a conceptual discussion piece with some
ideas at the end.



It seems to me that there are four ways in which documentation is used:

* Learning (learning new concepts/background)
* Browsing (getting an overview of what a module provides)
* Searching (looking for right function)
* Referencing (know function name, want to look at details)

Learning is about understanding the basics of a system. The user isn't
so much interested in details about individual functions but wants to
get a high level overview, wants to understand what can be done and how
things relate to each other. Think User's Guide in Erlang.

Browsing is when the user looks through the reference documentation to
get a bit of a feel for what's provided. The user may dip into the
details of a few functions but is mainly interested in getting an idea
what the module is useful for so that when she has an actual problem she
knows where to search.

Searching is when the user has a concrete problem in mind and is looking
for a function that solves it. The user doesn't know the name of the
function but has a rough idea what she wants it to do.

Referencing is when the user knows the name of a function and wants to
look at the details, for example to get some information about what the
function returns in some situation.



Looking at how well our current documentation supports these I end up
with this:

Learning is badly supported. There's the getting started guide but it
only covers the basics. It's a good introduction to the language but it
doesn't satisfy the need for deeper understanding and it misses some of
the less common topics (such as overriding functions). More in-depth
information is available but scattered around the reference manual. Will
a new user know that to get more in depth information about syntax-like
construct she needs to look at Kernel.SpecialForms? Erlang does this
better with the system of User's Guides.

Browsing is possible. There's no special support for it but the practice
of a moduledoc makes it doable. To get an idea of what a module offers
it has to be read in full however, there's no summary of what's
available (just the function names isn't always enough to get an idea
about what they do).

Searching is at the moment badly supported. It basically boils down to
looking at every function that has a name that might indicate it does
what the user wants. For example it took me a while to find a function
equivalent to lists:nth, turns out it's Enum.at. Such name discrepancies
can be a bit hard to navigate at the moment.

Referencing is excellently supported. The left hand side navigation
"bar" helps here as does the search function.



I have a few ideas on how to improve our documentation.

First of all let's replace the current function summary with a table of
function/macro type indication (F/M), function signatures and a short
description (taken from the first paragraph of a function's doc). The
left hand side "bar" already serves as a function quick reference. This
will greatly ease browsing and searching while being pretty easy to
implement (we have all the information available at the HTML formatter
already).

Next let's create a toplevel summary page for an
application/project/package (whatever you want to call it). This would
contain a summary table for the modules/records/protocols with a short
description for each (like with functions taken from the first paragraph
of the moduledoc). This sends users in the right direction. If there's a
README.md the information from it can be presented here.

It would be good to have a system of user's guides like Erlang does to
present information that isn't really tied to a specific module.

Finally I have an idea for improving specifically the main elixir
documentation. Currently that's generated by throwing elixir, eex,
ex_unit, iex and mix into the same documentation tree. While I think
it's good to have them all available from the same location it's not
optimal to have them mixed as if they were in the same application. Just
think of all the Mix modules annoying you when you want to look
something up in the standard lib.

There should be a level about a single application/project/package with
a summary of all the applications. So when you want to look something up
in the stdlib you first go to the main doc site then click on stdlib and
only see the modules from the standard library. If you decide you also
need ex_unit you just click on some "go up" link which takes you back to
the root doc site.

I'm not quite sure how to generate these docs, not sure who would be
responsible for them (this can tie into mix but also into expm). But I
do strongly believe that ultimately we will need a layer about the
single project in documentation.



Ok, that's enough for now. Post is long enough as it is. Comments are
very welcome, of course.

Greetings,

Peter Minten

[José Valim]

Thanks Peter,

I think all ideas are great. In fact a while ago Alexei (alco/true_droid) experimented with some of those, so you may find the previous discussion interesting.

Some comments:

 

First of all let's replace the current function summary with a table of function/macro type indication (F/M), function signatures and a short description (taken from the first paragraph of a function's doc). The left hand side "bar" already serves as a function quick reference. This will greatly ease browsing and searching while being pretty easy to implement (we have all the information available at the HTML formatter already).

Of all the ideas, this is the one I am the most unsure, simply because I haven't seen it in any other documentation tool (yet). I am not generally saying it is a bad idea or that it won't work but maybe there is something else we could do? Maybe we need a less "visually verbose" docs, so it is easier to scroll though? I can see how browsing could be improved by this proposal but searching would remain the same as you'd still need to use the browser search in order to find a particular text, no?

 

Next let's create a toplevel summary page for an application/project/package (whatever you want to call it). This would contain a summary table for the modules/records/protocols with a short description for each (like with functions taken from the first paragraph of the moduledoc). This sends users in the right direction. If there's a README.md the information from it can be presented here.

I think is a great idea. However, this feature seems to conflict with projects that have a README. Let's imagine we will break five projects: iex, mix, eex, ex_unit and elixir. Would it be preferable for us to use the automatically generated list of modules or to include a README in each project with specific instruction and guidelines? I think I lean more in favor of the README and then in the README we could list the most important modules in the system (manually done). Also, if we are going in this direction, we could consider being able to include other files besides the README in docs, allowing us to provide some sort of Erlang user guides.

 

There should be a level about a single application/project/package with a summary of all the applications. So when you want to look something up in the stdlib you first go to the main doc site then click on stdlib and only see the modules from the standard library. If you decide you also need ex_unit you just click on some "go up" link which takes you back to the root doc site.

This is a bit hard to make work today with ExDoc. Maybe we could simply point users to the current elixir-lang.org/docs page which would now link each project? Then the header "Elixir v0.10.2" and the link in each project would point to this /docs page. It is one of the things that is easier to push outside of the docs and instead add to elixir-lang.org website simply because elixir-lang.org is just html and we have more flexibility to do anything we want.

Ok, that's enough for now. Post is long enough as it is. Comments are very welcome, of course.

Thanks for starting the discussion!

[Alexei Sholik]

Great analysis, Peter! I like the breakdown to 4 areas of interest. The first one -- Learning -- will be better served by a dedicated manual, not affiliated with ExDoc. I've had some ideas of my own about this point, see here[1].

I very much like Julia's manual[2] that describes most of the language and has a good breakdown of the material into topics. Go's "Effective Go" guide[3] is a good example of an intermediate level documentation. It assumes readers already know some basics and goes deeper into best practices and idioms.

As for the reference documentation, I'm biased towards Go's approach here. They provide godoc which is a tool that collects doc-comments from code, generates plain HTML and can start a web-server locally to serve the HTML. This very server also serves their main docsite -- http://golang.org/pkg/

What I like most about it:

* having a backend gives us more flexibility and allows us to get away without Javascript where it's not needed

* it also allows us to implement a full-text search over the entire project's documentation and source code (JS implementation would not be efficient)

* each page is just plain text without mandatory navigation bars. It helps a lot when reading the docs on a mobile device (in ExDoc context, perhaps, a separate version of docs could be generated specifically for mobile)

[1]: https://github.com/alco/elixir/wiki/Growing-the-Docs

[2]: http://docs.julialang.org/en/latest/manual/

[3]: http://golang.org/doc/effective_go.html

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Best regards
Alexei Sholik

[Peter Minten]

On 08/25/2013 01:24 PM, Jos� Valim wrote:
> Thanks Peter,
>
> I think all ideas are great. In fact a while ago Alexei (alco/true_droid)
> experimented with some of those, so you may find the previous discussion
> interesting.
>
> Some comments:
>
>>
>> First of all let's replace the current function summary with a table of
>> function/macro type indication (F/M), function signatures and a short
>> description (taken from the first paragraph of a function's doc). The left
>> hand side "bar" already serves as a function quick reference. This will
>> greatly ease browsing and searching while being pretty easy to implement
>> (we have all the information available at the HTML formatter already).
>>
>
> Of all the ideas, this is the one I am the most unsure, simply because I
> haven't seen it in any other documentation tool (yet). I am not generally
> saying it is a bad idea or that it won't work but maybe there is something
> else we could do? Maybe we need a less "visually verbose" docs, so it is
> easier to scroll though? I can see how browsing could be improved by this
> proposal but searching would remain the same as you'd still need to use the
> browser search in order to find a particular text, no?

Take a look at
"https://github.com/pminten/ex_doc/tree/function-summaries-with-descriptions",
I've already made an implementation (slightly different from my
description above) and I must say, some problems with overly long
synopsises and default arguments aside, that it looks quite good to me
and that it's already making the documentation more useful to me. In
fact even if the patch is refused I think I'll keep it locally to run on
my own copy of elixir.

What I've implemented so far isn't uncommon btw, Javadoc works like this.

>
>> Next let's create a toplevel summary page for an
>> application/project/package (whatever you want to call it). This would
>> contain a summary table for the modules/records/protocols with a short
>> description for each (like with functions taken from the first paragraph of
>> the moduledoc). This sends users in the right direction. If there's a
>> README.md the information from it can be presented here.
>>
>
> I think is a great idea. However, this feature seems to conflict with
> projects that have a README. Let's imagine we will break five projects:
> iex, mix, eex, ex_unit and elixir. Would it be preferable for us to use the
> automatically generated list of modules or to include a README in each
> project with specific instruction and guidelines? I think I lean more in
> favor of the README and then in the README we could list the most important
> modules in the system (manually done). Also, if we are going in this
> direction, we could consider being able to include other files besides the
> README in docs, allowing us to provide some sort of Erlang user guides.

Maybe we could merge the README into the page with automatically
generated documentation.

As for user guides, definitely, we should have some way of doing that.
Maybe a (I don't know) users_guide directory and the files in there
would be concatenated (after sorting alphabetically) and turned into the
users_guide.

>> There should be a level about a single application/project/package with a
>> summary of all the applications. So when you want to look something up in
>> the stdlib you first go to the main doc site then click on stdlib and only
>> see the modules from the standard library. If you decide you also need
>> ex_unit you just click on some "go up" link which takes you back to the
>> root doc site.
>>
>
> This is a bit hard to make work today with ExDoc. Maybe we could simply
> point users to the current elixir-lang.org/docs page which would now link
> each project? Then the header "Elixir v0.10.2" and the link in each project
> would point to this /docs page. It is one of the things that is easier to
> push outside of the docs and instead add to elixir-lang.org website simply
> because elixir-lang.org is just html and we have more flexibility to do
> anything we want.

I would say you give ex_doc a link to the great big documentation root
and let it embed it in the generated docs, pretty much as you say.
Creating the great big documentation root page might involve a different
way of invoking ex_doc.

Essentially all ex_doc would need to accomplish this task is a list of
applications/projects/packages and their descriptions. I'm thinking, but
this is a very vague far from reality thought that you could have some
way of starting an ex_doc Erlang process and call it with that list.
Then it would be trivial for a tool that has the necessary info (a
package manager like expm) to create a new documentation root index page
whenever a package is added. Along the same lines it would be easy
enough to hack the makefile to generate a root index just for the stuff
in the elixir repo.

Greetings,

Peter

[Peter Minten]

On 08/25/2013 01:51 PM, Alexei Sholik wrote:
> Great analysis, Peter! I like the breakdown to 4 areas of interest. The
> first one -- Learning -- will be better served by a dedicated manual, not
> affiliated with ExDoc. I've had some ideas of my own about this point, see
> here[1].

I like the division from your GrowingTheDocs page and I do agree with
you to some extent that documentation isn't necessarily all ex_doc.
However for many projects it will be easier if the technical guide can
be generated with ex_doc. In practice for smaller projects than the main
elixir project the technical guide will be what Erlang calls a users
guide and very related to the documentation. I see advantages to having
those in the same style by the same system.

> I very much like Julia's manual[2] that describes most of the language and
> has a good breakdown of the material into topics. Go's "Effective Go"
> guide[3] is a good example of an intermediate level documentation. It
> assumes readers already know some basics and goes deeper into best
> practices and idioms.

Absolutely. Both the Julia manual and Effective Go are great examples of
documentation.

> As for the reference documentation, I'm biased towards Go's approach here.
> They provide godoc which is a tool that collects doc-comments from code,
> generates plain HTML and can start a web-server locally to serve the HTML.
> This very server also serves their main docsite -- http://golang.org/pkg/
>
> What I like most about it:
>
> * having a backend gives us more flexibility and allows us to get away
> without Javascript where it's not needed
> * it also allows us to implement a full-text search over the entire
> project's documentation and source code (JS implementation would not be
> efficient)
> * each page is just plain text without mandatory navigation bars. It helps
> a lot when reading the docs on a mobile device (in ExDoc context, perhaps,
> a separate version of docs could be generated specifically for mobile)

Personally I like the static HTML generation (no need to start a server
process whenever I want to look at local docs) but there's no reason not
to have both.

[Oren Ben-Kiki]

Great breakdown into the 4 different activities. I think that learning is the weak point of most/all the automatically-generated documentation tools (other than full-blown literate-programming tools, which nobody uses), and that this is something which can be addressed reasonably easily if we put our mind to it.

If learning is solved, browsing becomes much easier, so it should fall out of that solution.

Searching and referencing are easier - "all" it takes is work building proper search GUI, easily navigation for an identifier-based index, etc. But all the information needed to solve these already exists in the system, it is "just" a matter of properly presenting it to the user. I'm not arguing this isn't a lot of work :-)

Learning is different. As things stand in structured comment tools, the information needed is _not_ present in the system, which makes the task "impossible". A crucial piece is missing, which is reasonably easy to add.

In Elixir (as in many other languages), modules form a hierarchy. There is an implicit assumption that this hierarchy, as of itself, is sufficient to allow a newcomer to figure out how all the pieces fit together. Since the hierarchy is presented to the user in alphabetical order (that is, in essentially a random order), we expect the reader to somehow figure out in what order to access the system.

This doesn't work in practice. Being presented with a non-trivial system with multiple nested modules in a random order is a daunting task. Even if each level, module and function are documented, where does one even start? Where does one go on from there?

If, instead, the programmer had a way to also specify the order in which to present each level's sub-entries, then the reader would be presented with a hierarchical table of contents for the system that actually made sense - first things first and last things last.

This would make learning much easier. The newcomer could go through the system in some reasonable order; the documentation in different places could be written with a mind to what was "already presented" and what "will be presented later", and in general the whole system would become much more accessible.

One could argue that this hurts referencing and search, but I would argue that these shouldn't be served by the table of content; like a technical book has both a sensible TOC and an alphabetized index, the generated documentation should have a sensible TOC, an alphabetized index, and a search box - none of these replaces the other. Today's TOC is just a form of an alphabetized index, and is basically useless for learning.

Allowing the programmer to specify the order of the entries (in each level) isn't very difficult. First, we have the dependencies between modules, it is easy enough to specify that the default order is such that follows the dependencies (using alphabetical order to break ties and loops between entries). Second, we can allow the programmer to override/refine this default (partial) order by adding an attribute saying "put this entry after that one in the TOC".

For extra credit, one would allow doing the same thing inside each module; specifically, assume that the order that functions/types/etc. are given in the module's source file represent some logical progression, and preserve this in the generated documentation. Ideally, allow the programmer to insert "section" documentation inside the module source file, adding leaf sub-levels to the TOC. People typically do that anyway, using non-structured comments; all we need is a way to formalize them.

IMO, this would make a world of difference, and make the generated documentation closer to "true" literate programming, with a small change to the sources.

[Peter Minten]

As I understand you you are talking about the difference between
tutorial order (introduce more simple/basic things before more complex
ones) and reference order (easy to look up, typically alphabetical).

Honestly I'm not sure what my opinion on this is. On one hand if you can
add grouping of related functionality in the docs (I see that as more
important than ordering) it can make browsing large modules easier. On
the other hand it will likely require extra language constructs (or
advanced doc parsing which will take us away from simple markdown) and
I'm not sure if a module which requires grouping to be usable from a
documentation perspective isn't simply too big.

Greetings,

Peter

[Oren Ben-Kiki]

There's a difference between ordering and grouping of functions within a module, and ordering and grouping of modules.

We already group modules, using namespaces. All that's needed is a way to order the modules (and the namespaces, when they are nested). This would require a minor addition - adding a `@docafter foo` attribute or something like that. This would give you most of the benefit for presenting large systems in tutorial order, at a tiny cost.

Ordering functions within a module is trivial, they are already ordered in source code order. Simply preserving that order in the documentation would automatically give you tutorial order at no additional cost.

Grouping functions is a stickier issue. This would require a `@sectiondoc` attribute which one would be able to insert anywhere in the module, and would be injected into the documentation at that specific point. This is tricky because the attribute can be repeated so it can't be associated with the module itself. I guess it could be associated with the next documented entity - that is, allow @sectiondoc for anything that has a @doc?

There's no need to move away from simple markdown, the @sectiondoc is just a chunk of markdown inserted at that point. The user is free to include `#` or whatever in it as appropriate.

But even if you just gave the programmer control over the order, and declared that one module is one group without sections (one "shouldn't" have very large modules anyway :-), that would already go a very long way towards making the documentation of large systems comprehensible. Grouping is important (and we basically have it), but presenting the groups in the right order (which we don't have) is crucial for making the system accessible for newcomers.

[Peter Minten]

Thing is, while I see the benefit of using grouping to organize
documentation I don't believe using reference documentation as a
tutorial will work. Reference documentation is written in a completely
different way than a tutorial. A tutorial is written for sequential
reading: one concept flows into the next. Reference documentation is
written as lots of standalone bits of information.

You could apply some tutorial order to reference documentation but it
would still be lots of standalone bits of information. It wouldn't
become a tutorial or much easier to understand.

Greetings,

Peter

>> email to elixir-lang-core+unsubscribe@**googlegroups.com<elixir-lang-core%2Bunsu...@googlegroups.com>
>> .
>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>

[Oren Ben-Kiki]

It turns out that if one orders the reference documentation bits in some sane order, this still helps a lot even if one writes each documentation piece separately. Try it out on your favorite system and see for yourself :-)

Keep in mind that we assume there is documentation for each group (module, namespace) as well; such documentation by definition describes how the separate group elements fit together. Presenting that before the group elements is typically all you need to be able to make sense of the separate pieces, even when they are documented in "reference style".

Of course, the quality of the result depends on how much effort the programmer puts into the documentation. I'm not claiming a magic bullet here; I'm just saying that at a tiny cost, it is possible to gain a very large increase in the effectiveness of the generated documentation.

email to elixir-lang-core+unsubscribe@**googlegroups.com<elixir-lang-core%2Bunsubscribe@googlegroups.com>

.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[John Warwick]

I really like the taxonomy of documentation that alco and Peter have proposed. I think it makes it clearer as to which parts could be auto-generated from ex_doc and which parts needs to be written by hand.

I wonder if we also need to split the problem along another axis and consider which of these problems only apply to documentation for Elixir the language versus any other projects that might use ex_doc to generate less complex documentation. From that angle, I would worry about adding too much complexity to ex_doc; encouraging developers to write some documentation for their projects with giving them a more daunting task of filling in stubs for tutorials, guides, etc.

As multiple people have noted, none of this is a silver bullet. Unless we figure out a way to keep the bar low for writing useful documentation, very little will get documented.

thanks,

john

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

[Peter Minten]

I agree that we shouldn't require people to write user's guides, etc. On
the other hand it is good to have and a sign of a well developed library.

To go on somewhat of a tangent this ties in with something I've been
pondering about with regard to creating a healthy ecosystem. Haskell has
the Haskell platform which is basically a set of packages developed
separately but bundled together twice a year and offered as a convenient
download. The idea is that the platform is a stable base to develop on
and provides an extended standard library.

In the future I could imagine Elixir having a similar system. And when
you have that you can set some rules for packages to follow in order to
be eligible for inclusion, such as having a user's guide. That way you'd
encourage projects to have good documentation without making it harder
to start a project.

Greetings,

Peter

>> On Mon, Aug 26, 2013 at 4:22 PM, Peter Minten <peter....@online.nl<javascript:>

>>>> On Mon, Aug 26, 2013 at 11:59 AM, Peter Minten <peter....@online.nl<javascript:>

>>>>> email to elixir-lang-core+unsubscribe@****googlegroups.com<elixir-lang-
>>>>> **core%2Bunsubscribe@**googlegroups.com <javascript:>>
>>>>> .
>>>>> For more options, visit https://groups.google.com/****groups/opt_out<https://groups.google.com/**groups/opt_out>
>>>>> <https://groups.**google.com/groups/opt_out<https://groups.google.com/groups/opt_out>

>>>>>>
>>>>> .
>>>>>
>>>>>
>>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "elixir-lang-core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an

>>> email to elixir-lang-co...@**googlegroups.com <javascript:>.

[Oren Ben-Kiki]

I agree we shouldn't force people to write tutorials. I just think should enable them to do so.

Theology aside: What I suggest is adding a @docafter attribute to modules. If someone doesn't use it at all, then the order modules are listed within their parent module ("namespace") is alphabetical. If @docafter is specified, it overrides that order.

For extra credit, it would be nice if functions and types were listed in the order they appeared in the source file, instead of in alphabetical order, if @docafter (or maybe @docsourceorder?) was specified.

That's it.

It seems like a small change, and it would enable programmers who want to invest the extra effort in writing more tutorial-ish documentation the ability to do so. Of course, doing that would require a lot more effort in writing more complete text in the comments, giving examples, and so on.

Right now writing tutorial-ish documentation within ex_doc is impossible, which is a pity.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Peter Minten]

I remain unconvinced. But you could of course create a pull request and
see if it's accepted.

Btw, it's not at all impossible to write tutorialish documentation
within ex_doc: just create a really large moduledoc with the tutorial.
I'm not a huge fan of that, I would see use in ex_doc allowing you to
specify a list of markdown files and using that as a user's guide, but
this is what works today.

>>>> On Mon, Aug 26, 2013 at 4:22 PM, Peter Minten <peter....@online.nl<**

>>>>>> On Mon, Aug 26, 2013 at 11:59 AM, Peter Minten <peter....@online.nl<**

>>>>>>> email to elixir-lang-core+unsubscribe@******googlegroups.com<elixir-*
>>>>>>> *lang-
>>>>>>> **core%2Bunsubscribe@**googleg**roups.com <http://googlegroups.com><javascript:>>
>>>>>>> .
>>>>>>> For more options, visit https://groups.google.com/******
>>>>>>> groups/opt_out <https://groups.google.com/****groups/opt_out><
>>>>>>> https://groups.**google.com/**groups/opt_out<https://groups.google.com/**groups/opt_out>
>>>>>>>>
>>>>>>> <https://groups.**google.com/**groups/opt_out<http://google.com/groups/opt_out>

>>>>>>> <https://groups.**google.com/groups/opt_out<https://groups.google.com/groups/opt_out>
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> .
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> "elixir-lang-core" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an

>>>>> email to elixir-lang-co...@**googlegrou**ps.com<http://googlegroups.com><javascript:>.

>>>>>
>>>>> For more options, visit https://groups.google.com/****groups/opt_out<https://groups.google.com/**groups/opt_out>
>>>>> <https://groups.**google.com/groups/opt_out<https://groups.google.com/groups/opt_out>
>>>>>>
>>>>> .
>>>>>
>>>>>
>>>>
>>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to elixir-lang-core+unsubscribe@**googlegroups.com<elixir-lang-core%2Bunsu...@googlegroups.com>