Portfolio standard

[justintadlock]

I figured I'd start by opening up a topic for portfolios because I do have a little stake in this with my own plugin and it is one of the most common post types. However, I am willing to change my post type, taxonomies, and/or meta based on the results of this project. I hope others are willing to follow suit.

Here's my plugin: https://github.com/justintadlock/custom-content-portfolio

I know some people have used the portfolio post type. I believe that to be incorrect because a portfolio should be a group of items or projects. When we create post types, the name of the post type should represent the individual "thing". A taxonomy is a group of things.

To Do

• [x] Post Type Name
• [x] Taxonomy Name(s)
• [x] Metadata Keys

  Current proposed structure

  Post type

• project
• portfolio_project

  Taxonomies?

• portfolio
• portfolio_category

  Post meta?

Post meta keys should follow the standard of _post_type_metakey as outlined in the readme.md.

URL/Link?

This should be an external URL to a particular project's Web site.

• _project_url

Project start/end dates

These meta keys should denote a project's start and end dates. The meta values should be saved in YYYYMMDD format for easy comparisons using WP's meta query.

• _project_start_date
• _project_end_date

Project client

This meta key should represent the client for the project. Most likely, the project URL will link to this client's site. The meta value should be a text string with the client's name.

• _project_client

Other meta?

[hlashbrooke]

I prefer project for the post type name for the simple reason that it looks better in URLs. Anything with an underscore just looks a bit clumsy. I'll leave the meta data discussion for people with a deeper understanding of the requirements for this type of content.

[yojance]

How about having a start and end date as Meta. I recently worked with a construction company and their portfolio of construction projects had start and end dates.

For the Post type I would use project

[justintadlock]

I prefer project for the post type name for the simple reason that it looks better in URLs. Anything with an underscore just looks a bit clumsy.

The URL is irrelevant when it comes to the post type name. You set the URL with the rewrite argument.

[justintadlock]

How about having a start and end date as Meta. I recently worked with a construction company and their portfolio of construction projects had start and end dates.

Sounds like a good idea. We can propose:

• _project_start_date
• _project_end_date

The meta value should in a usable format too like YYYYMMDD or some variation that can be compared. I need to read up on dates a bit. Anyone want to chime in on a proper date/time format to save dates?

[yojance]

Yes, with YYYYMMDD we can compare dates. I can't think of a reason why the time would be relevant. I doubt we would require it to be that accurate.

[rogercoathup]

Would suggest following schema.org for fields / field types, where they have schemas that correspond to the suggested custom post type.

Will make it easier to access & display post meta that's microdata compliant.

As well as the higher level schemas, they also have definitions for how to represent lower level entities such as dates. i.e. https://schema.org/Date

[chryton]

Some options for fields:

• _project_client
• _project_location
• _project_gallery -- May want to include gallery of the project
• _project_videos -- May want to include videos with the project

There is also the fine line of what should go into categories and what should be meta values such as:

• Industry -- Think automotive vs. marketing vs. non-profit
• Type/Kind -- Think video vs. photo vs. multimedia

EDIT: I'd also like to +1 the start/end dates. Seems fairly common.

[michaelbeil]

I think that the _project_start_date and _project_end_date could be a great addition to this CPT.

The YYYYMMDD date format is best.

Good suggestions @chryton and @rogercoathup.

[justintadlock]

Industry -- Think automotive vs. marketing vs. non-profit

Could that be handled via a more general-purpose taxonomy? From what I've seen, users have many different uses for portfolios, so how they "categorize" them is wildly different.

Type/Kind -- Think video vs. photo vs. multimedia

Somewhat related: One thing I've been looking into doing is allowing post formats (specifically audio, video, image, and gallery) for portfolios.

_project_gallery -- May want to include gallery of the project _project_videos -- May want to include videos with the project

Do you think a _project_media would suffice? Or, are you seeing clients/users who need to display multiple media items per project?

_project_client

I'm assuming the meta value is simply a person's/company's name, correct?

_project_location

Format of City, State/Province, Country?

[rogercoathup]

City, State, etc. (address information) is all covered in https://schema.org/PostalAddress

Or, is there a reason why you wouldn't use the schema.org definitions?

[chryton]

@justintadlock:

Could that be handled via a more general-purpose taxonomy? From what I've seen, users have many different uses for portfolios, so how they "categorize" them is wildly different.

This is something I have been struggling with for a couple of years as it sometimes seems like it is a case-by-case basis as to whether or not there is a need for something as dynamic as a taxonomy. And from a performance perspective, is it worth querying the tax vs. just a meta query.

Do you think a _project_media would suffice? Or, are you seeing clients/users who need to display multiple media items per project?

I like the idea of _project_media but I can see users, especially agencies and those in a multimedia discipline, having multiple media types in a portfolio to showcase print, interactive, and video/audio pieces.

I'm assuming the meta value is simply a person's/company's name, correct?

Correct; just a simple string.

Format of City, State/Province, Country?

City, State/Province, Country works for me. I think mostly photographers/videographers will get the mileage out of these fields.

@rogercoathup I think schema.org is probably a good rule of thumb to go by but we shouldn't be fully whetted to it.

[julien731]

Regarding the project start and end dates, isn't it easier to use a timestamp instead of YYYMMDD? I think it's the most common format and it makes it very easy to interact with other date types. Of course I could be wrong, and in this case I'd be curious to know the advantages of one format over the other.

[justintadlock]

This is something I have been struggling with for a couple of years as it sometimes seems like it is a case-by-case basis as to whether or not there is a need for something as dynamic as a taxonomy. And from a performance perspective, is it worth querying the tax vs. just a meta query.

That's been what I've observed as well. It's nearly a case-by-case basis. That's why I think a general taxonomy would suffice (I've been calling this the portfolio taxonomy). For client work, you could change the labels for the specific client or not use the taxonomy. The underlying structure would stay the same.

Regarding the project start and end dates, isn't it easier to use a timestamp instead of YYYMMDD? I think it's the most common format and it makes it very easy to interact with other date types. Of course I could be wrong, and in this case I'd be curious to know the advantages of one format over the other.

WordPress saves the time as: 0000-00-00 00:00:00, which is YYYY-MM-DD hh:mm:ss. I could get on board with that format. I'd also like to tackle this particular item because I think it'll carry over into other post types in this project.

I'm often a fan of the YYYYMMDD format because it's really easy to compare dates, but some sort of official way of doing it would be good. For that, we should probably follow core WP's example.

[Screenfeed]

For my humble opinion:

• Post type: project,
• Taxonomies: if the post type is project, it should be project_category.

Another though here, perhaps we should define 2 default taxonomies: one hierarchical and another non hierarchical. Why? I think it would be a problem to switch from a plugin using a hierarchical taxonomy to a plugin using a non hierarchical taxonomy. And in the same way, what about hierarchical/non hierarchical post types? What would happen? :/

• Metas: agree for _project_metakey. For my portfolio I use the project url and coworkers (an integer representing a blogroll item, but it should be a "Person" CPT in our case).

Ok, I think it's not really relevant, but I think it worths mentioning another way for the start date: thanks to a small tweak from Nacin, we could use the post date instead (I think the publish date is not relevant in this case). Pros: native date queries, native rewrite rules and template hierarchy. Cons: only 1 start date, the start date is a post attribute while the end date is a post meta. I'm trying to use it in an events plugin for a client but it's too soon to say if it's a good idea.

[andreg]

Based on my experience, multiple images/videos (=media) attached to a single Portfolio entry are widely used.

Multiple _project_media could be OK, but is it reasonable to have the same field handle both types (IDs for Media Library items, string for video embeds) at once, or would it lead to confusion?

[Beth3346]

+1 project as the CPT name

One taxonomy that I use with my project CPT is Technologies/Tools. WordPress, Ruby on Rails, PhotoShop for my portfolio website. I've also used it as a meta_key but it makes more sense to me as a taxonomy. Especially since a project team could use multiple technologies/tools.

[justintadlock]

I listed project as the post type name. I believe we have a consensus on this now.

Ok, I think it's not really relevant, but I think it worths mentioning another way for the start date: thanks to a small tweak from Nacin, we could use the post date instead (I think the publish date is not relevant in this case)...

I think in this scenario, it's best to stay away from that since we're dealing with two different dates. If we were to go that route, I'd think it'd be preferable for the _project_end_date to be assigned as the post date.

Based on my experience, multiple images/videos (=media) attached to a single Portfolio entry are widely used.

From my limited experience, the opposite has been true and is probably a result of how I demo its use.

Multiple _project_media could be OK, but is it reasonable to have the same field handle both types (IDs for Media Library items, string for video embeds) at once, or would it lead to confusion?

That's actually pretty easy to do from a code perspective. I've actually got the code to handle multiple scenarios (aside from checking an ID, which is pretty easy with is_int()). Personally, I've just been letting the user add whatever media they want to the content, then extracting it from the content. So, it's a pretty easy switch for me to grab the media and sift through it if it's saved as metadata.

---

Everyone, it looks like we're stuck on media handling right now. Anyone want to write a good proposal for how this should be handled?

[julien731]

Using multiple _project_media sound like a good idea to me. It's easy to retrieve and loop. The only question I can think of is: what if the user wants to manually set the medias order? Is it a scenario we want to anticipate? If so then we'll need more info, but if not I can't think of any good reason why not using multiple _project_media keys.

[andreg]

From a data stand point, _project_media makes sense whatever value, integer or string, it ends up with. Concerning ordering, @julien731, that sounds more like an implementation detail to me: correct me if I'm wrong, but each time you save the Portfolio entry, you would delete existing _project_media fields, and re-save them in the correct order (again, needs implementation).

[andreg]

@justintadlock, writing these ideas down:

This meta key should represent a media attachment to the Portfolio entry. Acceptable values for this meta are integers and strings.

In case of an integer value, the value represents the ID of the attachment in the WordPress' Media Library, while a string would represent the URL to an external resource that can potentially be embedded.

Multiple _project_media meta fields can be associated to the same Project entry.

[julien731]

@andreg You're right indeed. This should be an implementation matter, in which case I completely with your comment.

[mor10]

A thought on taxonomies related to projects: In our builds we often use taxonomies that are shared between services, projects, and testimonials. That way taxonomy-related projects and testimonials can be pulled in when a service is displayed etc. For most projects it makes sense to anchor this relation through Services so each service will have an equivalent service taxonomy term (eg. Legal Services has the services taxonomy term "legal-services"). Then when you are looking at a project where legal services was provided info from the Legal Services service and testimonials about Legal Services can be pulled in easily.

[ericnicolaas]

A little late to the party here, but I'd like to argue against the use of project for the post type. Project is a broad term and could be used in very different contexts. Consider an NGO that has multiple projects, or a science lab's research projects. These are perfectly valid uses of the word project but it wouldn't make sense to define them with a portfolio post type.

I would suggest portfolio_project instead. I know it's a little more verbose, but it's more specific to the fact that this is a project within a portfolio.

[justintadlock]

I would suggest portfolio_project instead. I know it's a little more verbose, but it's more specific to the fact that this is a project within a portfolio.

+1

[justintadlock]

I've updated the wiki to reflect our most current standard: https://github.com/justintadlock/content-type-standards/wiki/Content-Type:-Portfolio

I'm going to cover where we're at and what we need to do. We're pretty close to a working standard for portfolios, which is awesome!

Post type

I am in agreement that portfolio_project is the best name. Because this is a community standard, this can be changed, but I feel like it's the best option for the reasons @ericnicolaas pointed out.

Metadata

I feel like we're at a good point with metadata. We've covered the items that are going to be used a lot. There may be other things. We can take on those as they come up.

As far as I'm concerned, this part of the standard is complete, pending the discussion on meta naming standards. See: #7

Taxonomies

This is the next big hurdle. I've given this quite a bit of thought over the last few days because I knew it could be a point of contention. What I believe we should do is keep this extremely basic. I like some of the ideas I'm seeing and have worked with scenarios as @mor10 described. Some things can be really niche-oriented or specific to certain clients. I don't think either of those are going to be extremely relevant to our goals of setting up a base standard.

My proposal is that we create a standard naming convention for both a hierarchical and non-hierarchical taxonomy for portfolio projects. It's possible that some plugins will use one, both, or even tack on additional taxonomies as they see fit. We should just cover the basics.

With that said, here's the two general-purpose taxonomies proposed:

• portfolio_category (hierarchical)
• portfolio_tag (non-hierarchical)

Discuss.

[mindctrl]

Working with both clients on custom projects and customers at a theme shop, I've seen a lot of requests for doing both video and image galleries in a portfolio item. Using a single meta key named _project_media would make this much more annoying than having something like _project_videos and _project_images, or whatever they'd be named. Also, the surrounding markup for videos and images probably needs to be different in many cases.

There are ways to work around that and/or to detect what kind of information you're getting from the key, for sure, but code starts getting ugly and unnecessarily complex, especially if you can just store the data in separate keys.

[justintadlock]

So, are you proposing that we create meta keys for every possible type of media?

_project_video
_project_audio
_project_image
_project_powerpoint
_project_xxx

Or, maybe stick with the big three and have a general-purpose meta key?

_project_video
_project_audio
_project_image
_project_multimedia

The first could take us down the rabbit hole. I don't really find it hard to use a single meta key, but that's probably because I've already got most of the tools on hand for handling this sort of thing. With WP's new embed and other media-related features, this has become extremely simple.

Having multiple meta keys for media can also get complex because then we'd get into having multiple meta values for each one of those keys unless we're shooting for a single value for a single key.

[justintadlock]

I spent the better part of the day reviewing portfolio plugins and themes. Ultimately, most of them have these things in common or similar:

• CPT (varying names)
• Hierarchical taxonomy (types, categories)
• Non-hierarchical taxonomy (tags)
• Support for the featured image
• Support for the post editor

Metadata for media

Interestingly, most of these have no alternative way for uploading media for the project other than simply putting it in the post editor. WordPress makes adding media to the post content stupid simple these days. Based on this topic and from experience, users are going to put all kinds of different media into their portfolio projects, even multiple media in a single project. I'm not sure we should try to account for that with custom meta fields and just allow the user to input their media directly into the post editor.

My proposal is going to be simple for the media metadata. The standard should simply support the featured image.

Let's think about how we actually use and build for portfolios. Generally, a project is going to have a single indentifying piece of media, whether this is an image, video, gallery, or whatever. As developers, this is something we can easily identify.

Ultimately, I don't think metadata is required for setting the "featured" media because it's easy to grab that. If you couple that with support for something like WP's post formats, it becomes even easier.

Here's a demo of easily pulling audio and video from the post content and positioning it where I want:

• http://locallylost.com/stargazer/2007/11/24/somethin-bout-a-truck/
• http://locallylost.com/stargazer/2013/11/24/big-buck-bunny/

Taxonomies

I think we could follow Jetpack in this regard with "Portfolio Types" (hierarchical) and "Portfolio Tags" (flat). I've updated the wiki to reflect this for now.

[mindctrl]

Definitely wasn't proposing a key for all types, but I do like the 3 majors with a general purpose one. But if there's a solid way to reliably pull content out of the post_content and use anywhere else that's great. It particularly lends itself to new and creative ways of designing pages versus the same ole same ole, though it's not intuitive to rip content out of where someone places it and show it elsewhere. What are you using for those demos?

Aside: Jetpack 3.1 landed today with their custom content type implementation. They pushed it ahead of schedule for some reason.

[georgestephanis]

@mindctrl Ahead of schedule? What schedule were you working on? :P

[mindctrl]

@georgestephanis the one where you said it would be "two months ish".

[justintadlock]

I use this code: https://github.com/justintadlock/hybrid-core/blob/2.0/classes/hybrid-media-grabber.php

It was developed specifically for this sort of thing.

[georgestephanis]

@mindctrl: Ah, thought you had meant that 3.1 was ahead of schedule. Portfolios got pulled in to 3.1 as we reset the freeze. It was mentioned fairly strongly in Krogsgard's post, so I assumed folks had realized, sorry if it caught you by surprise.

@justintadlock Relevant to that: https://github.com/Automattic/jetpack/blob/master/class.media-extractor.php is what we use on wpcom, if any of it useful. :+1:

[devinsays]

Just caught up on this thread and agree with the updated naming conventions (for both post types and taxonomies).

I agree that standards aren't really necessary at this point for media meta. The featured image and extracting the gallery shortcodes work well enough for everything I've used it for. But if we do go in that direction it might be useful to look at how structured data for post formats was proposed (see: https://core.trac.wordpress.org/ticket/20564).

Do we want to recommend icons for custom post types as well? "dashicons-portfolio" is the obvious choice, of course.

Looks like JetPack pushed this out the portfolio post type with a prefix (https://github.com/Automattic/jetpack/blob/master/modules/custom-post-types/portfolios.php). @georgestephanis, would y'all be willing to drop the prefix and have a script update the post types? I think if the Jetpack team adopts this it will have a much better chance of becoming a standard.

On that note, does anyone have code for a post type updater script they'd be willing to share? I'd be willing to implement this for http://wordpress.org/plugins/portfolio-post-type/.

Thanks for guiding the conversation @justintadlock.

[mindctrl]

The more I think about it, the more I don't like the idea of visually ripping content from where someone places it and relocating it elsewhere. The code is quite elegant, but the user experience doesn't make much sense at all. And with efforts being put into front-end editing capabilities, which presumably will land in core, it makes even less sense and might not even work at all. With that in mind I do think it's important to agree on some kind of media meta standards.

+1 on @devinsays idea of Jetpack dropping the prefix. I've scripted post type conversions before by looping through with set_post_type.

[andreg]

+1 on what @mindctrl said. Extracting data from the content might only make sense in posts, where we a) don't have a clear standard defined for those meta data, b) tons of blogs all around the world that have been working without such clear standard for years.

I have the feeling we should try to agree on something more structured.

Also, let's keep in mind that meta data could also be serialized. If we agreed on an array structure to be serialized, all kinds of interest possibilities would open.

[hchouhan]

Just adding my few cents.

If we could keep this simple, it would be easier to finalize and then implement those changes in existing plugins, etc.

Some of the custom meta key's proposed such as Project URL, Dates, Client, etc. are common and we can all agree on. I like the approach Justin uses as it keeps things simple.

[justintadlock]

Just to make things clear, I'm not proposing that extracting media from the post content be a part of the standard. It was simply mentioned as a way of pulling it from the post in the case that it was needed in such a manner. We're not concerned so much with what themes do to present the content.

The proposed standard is that we have no media meta other than the featured image. This doesn't mean that plugins can't come in and implement stuff on top of the standard. We'd never be able to agree on every possible scenario, and that's not the ultimate goal.

I think we should let the media meta discussion rest for a bit. Then, if someone comes along, opens a new ticket, and has a solid plan of action for handling this sort of thing, we look at possibly bringing that into the standard.

Do we want to recommend icons for custom post types as well? "dashicons-portfolio" is the obvious choice, of course.

It'll be a part of this: https://github.com/justintadlock/content-type-standards/tree/master/portfolio

But, I wouldn't go so far as saying one icon is a standard. That icon doesn't really matter for our purposes.

If we could keep this simple, it would be easier to finalize and then implement those changes in existing plugins, etc...

That's what I'm thinking. Right now, I think we pretty much have an agreement on how this should play out (other than the media meta).

[nvartolomei]

Agree for project post type name.

Why use Portfolio Types as taxonomy for category? It's definitely Project Categories or just Portfolio, better first one for naming consistency.

The same goes for tags, I think it's better to name them Project Tags, because you don't tag portfolios (categories) but Projects are the thing being tagged.

[justintadlock]

Agree for project post type name.

I think we're pretty set on portfolio_project at this point unless a good argument can be made otherwise.

Why use Portfolio Types as taxonomy for category? It's definitely Project Categories or just Portfolio, better first one for naming consistency.

There hasn't been much discussion on Categories vs. Types. There's no "definitely" to it. There are many different ways you could potentially name this. If you feel like "Categories" is the better name, but we go with portfolio_type as the standard, it doesn't mean you can't use custom labels.

I'm fine with either categories or types. The Portfolio Post Type plugin uses categories. Jetpack uses types.

The same goes for tags, I think it's better to name them Project Tags, because you don't tag portfolios (categories) but Projects are the thing being tagged.

It's not necessarily true that a type/tag is just for the portfolio project. A taxonomy name doesn't have to be named with a particular post type in mind. It can be broader than that.

For example, a portfolio can have additional post types via add-on plugins that can make use of these taxonomies. Plus, all three of the major portfolio plugins (Jetpack, Portfolio Post Type, Custom Content Portfolio) that we've looked at use portfolio as a prefix. It's probably best to draw from existing solutions as much as we can.

[nvartolomei]

There hasn't been much discussion on Categories vs. Types. There's no "definitely" to it. There are many different ways you could potentially name this. If you feel like "Categories" is the better name, but we go with portfolio_type as the standard, it doesn't mean you can't use custom labels.

You just don't name categories for posts as blog_type, are you? I think it's clear that categories should remain categories, and like posts have categories so projects should have them. It's again about naming consistency and logic.

[justintadlock]

You just don't name categories for posts as blog_type, are you? I think it's clear that categories should remain categories, and like posts have categories so projects should have them. It's again about naming consistency and logic.

We're dealing with the portfolio standard, so what blog posts do doesn't play into this.

I'm not against using categories. We've not decided whether we want categories, types, and/or some other hierarchical taxonomy for the portfolio standard.

This argument about calling it the wrong thing does not help further the conversation. Stick to why you'd rather have a category taxonomy instead of another hierarchical taxonomy. Or, just let folks +1 a taxonomy name they prefer.

[justintadlock]

Anyone else want to weigh in on the hierarchical taxonomy used? Categories are more of a general-purpose taxonomy. Types implies something more specific. I'd love to get some feedback from someone @Automattic on why they chose the types taxonomy.

Both @nvartolomei and I like Categories. The Portfolio Post Type plugin uses this taxonomy now. I consider that +3 votes for categories.

Jetpack uses the Types taxonomy. I consider that +1 vote for types.

This is the only outstanding issue left for the initial portfolio standard, so if we knock it out, we can move on to other things.

[michaelbeil]

+1 for Categories.

[hchouhan]

+1 for Categories. But considering Jetpack is using types, it would be lot easier if everyone just use "types" to avoid clash. I hope Jetpack developers contribute as I love the speed at which this is going through.

[GaryJones]

What's the naming standard for filtering the post type and taxonomy arguments in this?

As per my comment on Justin's blog post, having the filter names consistent means customising labels (i.e. to change the taxonomy between Category and Type if the default isn't what your client wants) or rewrite slug etc. will work whichever supporting plugin is used.

[justintadlock]

What's the naming standard for filtering the post type and taxonomy arguments in this? ...

I don't think a standard args hook is needed. Whether a plugin wants to allow this to be filtered, should probably be left up to the plugin author. I believe this project should mostly be concerned with how data is stored.

Plus, you can do a whole lot with these hooks:

• registered_post_type
• post_type_labels_{$post_type}

And, these functions:

• add_post_type_support()
• remove_post_type_support()

If needing to change rewrite rules, there are hooks in place there. That's just the start. There are loads of hooks WP already fires out of the box that allow you to change a lot of things.

[nvartolomei]

We're dealing with the portfolio standard, so what blog posts do doesn't play into this.

@justintadlock actually they do, because it is in the same ecosystem, kinda.

@michaeldcain, would you be so kind to join the discussion?

[justintadlock]

We're dealing with the portfolio standard, so what blog posts do doesn't play into this.

actually they do, because it is in the same ecosystem, kinda.

We're voting on our preferred hierarchical taxonomy right now. Your vote has been tallied.

[michaeldcain]

@nvartolomei I've been following along and agree with the direction that @justintadlock has been leading things. It's good to see balance in deciding what should be basic Portfolio functionality vs more case-by-case features. I'm also happy to see @devinsays weighing in, since I've had a chance to talk to him directly about Portfolios in WordPress, and he has some excellent thoughts and ideas on the matter.

I can't speak for Automattic or the Jetpack team in terms of the future of the CPT in Jetpack, since that'll need to be another discussion, but I can give the reasoning behind the decisions we made (myself, @iamtakashi, and @thomasguillot) when we created the CPT on dotcom.

In general, simplicity for the user was our guiding principle while developing the plugin. There are hundreds of themes out there (both on dotcom and dotorg) that refer to themselves as "Portfolio" themes without explicitly supporting a Portfolio CPT. Thus, we shied away from things like custom meta in favor of supporting basic functionality that could be reflected in almost every theme - post formats, featured images, and custom taxonomies. The goal was to allow a user to turn on our CPT even in themes that weren't built for it, and have the template hierarchy do most of the heavy lifting.

That being said, we weren't opposed to custom meta in the CPT, just decided to leave it out for a v1. I think the meta proposed above is common enough to be included in the standard, it just unfortunately puts a requirement on the theme developer to expose it on the front-end.

Naming: It's already been decided, and I agree with @ericnicolaas that that CPT should be registered as portfolio_project due to the vagueness of project alone. In the Jetpack CPT, we settled on jetpack-portfolio since prefixing was all the rage before this discussion and most people call them "Portfolio CPTs", but in the labeling, stuck with using "Projects" inside of a "Portfolio" menu item.

Taxonomies: I like having one hierarchical and one non-hierarchical to let the users mold them to their own needs. I think they should be prefixed project_ to follow suit with post_, and although we settled on "Project Type" for our hierarchical taxonomy, I think I lean more toward the more generic "Project Category" to not encourage a specific taxonomy purpose in the standard CPT.

Other: I mentioned above that enabling Post Formats and Featured Images will fit most users' needs, give theme developers a lot to work with, and will also allow for a lot of backwards compatibility in existing Portfolio themes. I like the custom meta proposed in the standard since they're pretty common across Portfolio implementations, but want to reiterate that I'm happy to see @justintadlock keep it to the most basic of meta examples - plugins can expand on those options if need be.