NAME

Greetings - Quick Greetings for the world

More documentation coming soon, we promise.

```

Interestingly, now that we have added the `NAME` section to our documentation, `Dist::Zilla` can successfully build our module without the `# ABSTRACT` comment that we had you create in the first tutorial. So go ahead and delete that comment from your module.

Save your work and issue the `dzil build` command and check out the README file now in your distribution and you should see that your module's POD was inserted into the README file. Nice. Go bake yourself a well-deserved cookie.

## Double Your Pleasure with Two `README` Files

So now you've got a plain old text file for reading your module's plain old documentation. Kind of boring. All the cool kids are using GitHub these days and the preferred format for `REAMDE` files there is markdown. We don't want you looking like a stick in the mud, so let's hook you up with a fancy markdown version of your `README` file by adding the following to the end of your `dist.ini` file:

```

[ReadmeAnyFromPod] type = markdown filename = README.md

```

Run the `build` command:

`dzil build`

Look inside your distribution. Awesome, you now have a plain text `README` file and a fancier, markdown version `README.md` automatically generated for you without having to know a lick of markdown syntax.

Let's take a moment to understand what you added to the `dist.ini` file. The first line in brackets is, of course, the name of the plugin. In `.ini` file parlance, bracketed text starts a new **section** in the `dist.ini` file.

Below and within this section you supplied two **parameters,** using the standard key/value pair `.ini` syntax. Because they are in the section our plugin is named after, they got passed to the plugin. Think of the parameters as custom commands given to our `README` insertion robot on the assembly line. As you might assume by looking at the parameters, you instructed the `[@ReadmeAnyFromPod]` plugin to generate a `README.md` file using the `markdown` syntax. Each plugin has different parameters that it will accept which you can discover by carefully reading its documentation.

As we saw earlier, the `[@Starter]` bundle automatically generated the plain text `README` file using the `[ReadmeAnyFromPod]` plugins. So what we are doing here is telling `dist.ini` to run the `[ReadmeAnyFromPod]` plugin a **second time** to generate the markdown version of our `README.md` file.

But the purists out there believe a markdown file has no business being on CPAN. No problem! You can direct `[ReadmeAnyFromPod]` to save the markdown version to the top level of your `Dist::Zilla` directory instead of inside your distribution by adding the following line to the `[ReadmeAnyFromPod]` section of your `dist.ini` file:

`location = root`

Try it out and run the `build` command and you'll see your `README.md` file output alongside your distribution's directory instead of inside it:

`dist.ini Greetings-0.002 Greetings-0.002.tar.gz lib README.md`

Now your CPAN repository will remain unpolluted by those new-fangled markdown files, keeping the purists happy.

Alright, we've given you a very tiny taste for how to gain more control over how your plugins work. We'll show you many more powerful and useful tricks later. Now it's time to take a break from the world of plugins and start talking about another fundamental area of knowledge `Dist::Zilla` calls "minting profiles" but that we call "blueprints."