Orchard-Training-Demo-Module | Demo Orchard Core CMS and Orchard

It seems you are confusing properties of a content part with fields of a content part, which are two different concepts in Orchard.

Parts are regular C# objects that can have regular C# properties. Using such properties is the valid and mainstream way for developers to extend the CMS and build custom parts in Orchard.

Fields are smaller units of contents (typically a single string, or a number, or an image, etc.) that can be dynamically added to a part, trough code or through the admin's content type definition editors. They have the advantage that the administrator of the site can add, remove and modify them at runtime.

It's very understandable that you'd confuse them: they are both name/value thingies that you can attach to a part. In terms of actual usage, a good way to choose between the two is to ask the following question:

Is this a core property that is firmly attached to the part concept I'm building, or something that would be nice for administrators to attach to it if it makes sense to them?

For example, if I build a commerce product part, it would make sense that the SKU and price would be part properties. Now a product photo is different in that not all products may necessarily have a photo, some may have several, may be videos, who knows? It's just not an intrinsic property that makes a product a product. So make that a field (a media picker field to be specific).

To get back to your specific example, you should not be adding that field in your migration: it's basically creating something that looks like it's your Description property, but actually is a Description field, in addition to your property of the same name.

The reason why your part properties don't appear on your editor is that you aren't done with your part. You still need to build a driver, and views for it (the field didn't need that because they were already built by whoever built that field).

As a side note, I think the good Lombiq folks made a lousy choice by giving that Biography property the TextField type. It's very confusing, and should really be a string, in my opinion, and so should your Description property.