Roadmap page has numbered-only list when should be a mix of numbered and unnumbered

[rffontenelle]

about / roadmap page in the website shows a numbered list of 17 items and this doesn't seem to be the expected result by looking at the code:

pandas/web/pandas/about/roadmap.md

Lines 108 to 145 in 05de253

	1. Label indexing must never involve looking in an axis twice for the same label(s).
	This implies that any validation step must either:
	* limit validation to general features (e.g. dtype/structure of the key/index), or
	* reuse the result for the actual indexing.
	2. Indexers must never rely on an explicit call to other indexers.
	For instance, it is OK to have some internal method of `.loc` call some
	internal method of `__getitem__` (or of their common base class),
	but never in the code flow of `.loc` should `the_obj[something]` appear.
	3. Execution of positional indexing must never involve labels (as currently, sadly, happens).
	That is, the code flow of a getter call (or a setter call in which the right hand side is non-indexed)
	to `.iloc` should never involve the axes of the object in any way.
	4. Indexing must never involve accessing/modifying values (i.e., act on `._data` or `.values`) more than once.
	The following steps must hence be clearly decoupled:
	* find positions we need to access/modify on each axis
	* (if we are accessing) derive the type of object we need to return (dimensionality)
	* actually access/modify the values
	* (if we are accessing) construct the return object
	5. As a corollary to the decoupling between 4.i and 4.iii, any code which deals on how data is stored
	(including any combination of handling multiple dtypes, and sparse storage, categoricals, third-party types)
	must be independent from code that deals with identifying affected rows/columns,
	and take place only once step 4.i is completed.
	* In particular, such code should most probably not live in `pandas/core/indexing.py`
	* ... and must not depend in any way on the type(s) of axes (e.g. no `MultiIndex` special cases)
	6. As a corollary to point 1.i, `Index` (sub)classes must provide separate methods for any desired validity check of label(s) which does not involve actual lookup,
	on the one side, and for any required conversion/adaptation/lookup of label(s), on the other.
	7. Use of trial and error should be limited, and anyway restricted to catch only exceptions
	which are actually expected (typically `KeyError`).
	* In particular, code should never (intentionally) raise new exceptions in the `except` portion of a `try... exception`

[michellesweering]

take