add a name: and mark it as required

src/site/docs/pub-package-manager/pubspec.markdown

 ---
 layout: default
 title: "Pub: What is a Pubspec?"
 description: "More details about the pubspec format and contents."
 has-permalinks: true
 ---
 
 # {{ page.title }}
 
 Every pub package needs some metadata so it can specify its dependencies. Pub
@@ skipping 11 matching lines @@
   Have you been turned into a newt? Would you like to be? This
   package can help: it has all of the newt-transmogrification
   functionality you've been looking for.
 dependencies:
   efts: '>=2.0.4 <3.0.0'
   transmogrify: '>=0.4.0'
 {% endhighlight %}
 
 ## Name
 
-Every package needs a name. When your stellar code gets props on the world
+**Required**: every package needs a name. When your stellar code gets props on the world

[Bob Nystrom, 2012/08/29 17:47:32]

This seems a bit ugly to me. Is it really necessary?

[sethladd, 2012/08/29 19:49:18]

I care less about how we format this, but when I look at this as technical
documentation, we need to specify what is required and what is optional (in a
clear and concise way)

I'm open to how to say "required" in clear way. Ideas? Maybe a table of fields,
marked with required and optional?

This is great commentary, but also useful is the technical conciseness.

[Bob Nystrom, 2012/08/29 19:53:50]

Right now, there are only three fields, and one of them is required so I don't
know if we're quite ready for a table yet. But we will be adding more metadata
relatively soon. How about we iterate on this then?

[sethladd, 2012/08/29 20:01:41]

I changed it a bit in the latest patch. I think a table would be fine now,
actually, but it's not a big deal.

I can image:

field, required, type (num, strong, bool), format, notes

Also, this is the kind of thing we can do for you after things settle down a
little.

 stage, this is what they'll be hollering. Also, it's how other packages will
 refer to yours, and how it will appear on [pub.dartlang.org][pubsite], should
 you publish it.
 
 It should be all lowercase, with underscores to separate words,
 `just_like_this`. Stick with basic Latin letters and Arabic digits:
 `[a-z0-9_]` and ensure that it's a valid Dart identifier (i.e. doesn't start
 with digits and isn't a reserved word).
 
 Try to pick a name that is clear, terse, and not already in use. A quick search
 on [pub.dartlang.org][pubsite] to make sure nothing else is using your name can
 save you heartache later.
 
 ## Version
 
-Every package has a version. No one really gets excited about versioning, but
+Every package has a version. A version number is required to host your package on

[Bob Nystrom, 2012/08/29 17:47:32]

Long line.

[sethladd, 2012/08/29 19:49:18]

Done.

+[pub.dartlang.org][pubsite], but can be omitted for local-only packages. If you
+omit it, your package is implicitly versioned `0.0.0`.
+
+No one really gets excited about versioning, but
 it's a necessary evil for reusing code while letting it evolve quickly. A
 version number is three numbers separated by dots, like `0.2.43`. It can also
 optionally have a build (`+hotfix.oopsie`) or pre-release (`-alpha.12`) suffix.
 
 Each time you publish your package, you will publish it at a specific version.
 Once that's been done, consider it hermetically sealed: you can't touch it
 anymore. To make more changes, you'll need a new version.
 
 When you select a version, follow [semantic versioning][]. When you do, the
 clouds will part and sunshine will pour into your soul. If you don't, prepare
 yourself for hordes of angry users.
 
 [semantic versioning]: http://semver.org
 
-A version number is required to host your package on
-[pub.dartlang.org][pubsite], but can be omitted for local-only packages. If you
-omit it, your package is implicitly versioned `0.0.0`.
-
 ## Description
 
 This is optional for your own personal packages, but if you intend to share
 your package with the world (and you should because, let's be honest with
 ourselves, it's a thing of beauty) you must provide a description. This should
 be relatively short—a few sentences, maybe a whole paragraph—and
 tells a casual reader what they might want to know about your package.
 
 Think of the description as the sales pitch for your package. Users will see it
 when they browse [pub.dartlang.org][pubsite]. It should be simple plain text:
@@ skipping 222 matching lines @@
 <aside><div class="alert alert-warning">
 
 Note that <code>&gt;</code> is also valid YAML syntax so you will want to quote
 the version string (like <code>'<=1.2.3 >2.0.0'</code>) if the version
 constraint starts with that.
 
 </div></aside>
 
 [pubsite]: http://pub.dartlang.org
 [semantic versioning]: http://semver.org/