Rewarding the contributor as focus
I believe it is important for any community site to focus on rewarding and enabling the contributor.
To do that, it is important that the author as a piece of metadata for all pieces of content be treated with a certain degree of reverence, and the author, as an identity, treated as an individual for whom progress is possible. It should be obvious from the moment the site is entered, that the visitors contributions are both welcomed and encouraged and the bar to offering contribution is low.
This view of the importance of inviting authors sets an immediate bar for user authentication. Signing up to be a card-carrying member of the Jenkins User Community should be immediate and obvious and with it, should come the right to establish a personal page and post blog articles, comment on the articles of others, and contribute plugins. Also implied by this emphasis is that comments and feedback mechanisms be associated with most if not all portions of content managed by the site. Visitors should be able to rate plugins, vote up or down on the value of a proposed feature, and comment on all written material. Ideally, those contributions should remain associated with that user, helping them build up clout and credibility within the community and mitigating the risks of anonymous mischief. A sensible measure for the success of the site would be the increased rate of community membership post site launch compared to prior to the site launch. An additional success metric would be the amount of community driven content created through the site.
Inspirational sites:
- http://www.smashingmagazine.com/
- http://www.deviantart.com/
- https://www.behance.net/
- http://www.ravelry.com/
Types of contributable content
The five major types of content distributed by Jenkins-ci.org today are:
- The Jenkins Download!
- Blog articles
- Plugins
- rudimentary events calendar
- OSS doc (such as it is, today)
Resources linked from the site, but with independent domains and credentials include:
- Bug tracker
- Google group mailing lists
- Twitter account page (and a few other Jenkins SM pages)
- Link to IRC
Any new Jenkins site must at least match the existing site in terms of its delivery the 5 major content types and integrate at least equally well the 4 linked resource types. Ideally, all members of the Jenkins community should be able to author or comment upon each of these content types with a single authentication and minimal editorial review. In terms of volume, the blog articles, represent the primary content of the site.
Blogs
Today, blog articles can receive visitor comments. This does not seem to be a particularly common practice on the Jenkins-ci.org site, but perhaps some design adjustments and a common Jenkins Community sign-on could improove that. In addition, blog articles should be browsable by category and author as well as by date. Blog posts, in addition to being easy to re-tweet as they are today, should be 'favorite-able' within the site as well. This gives the site an additional piece of metadata by which articles can be surfaced and credibility can be awarded to contributors. Further it gives a basic bit of customizability for repeat but casual site visitors (this is an aspirational feature). While it is essential to at least match the existing date-only blog sorting, these additional enhancements of favoriting, tracking authorship and improved sorting, searching and browsing should be weighed against other priorities.
Plugins
Andy Pemberton <apemberton@cloudbees.com> build a nice little Drupal prototype of a review engine for Jenkins Plugins. I believe it is important that we allow comments and ratings for plugins as quickly as we can to combat a major complaint about Jenkins, namely, 'how do I find the quality in the sea of plugins?' Further, plugins should be browsable by a number of criteria, including, installs, review score, author, use purpose, newness, and adoption rate. An 'application store' similar to those by Google and Apple are reasonable aspiration comparisons. I have recently been demoing a prototype for an [improved plugin manager|https://www.youtube.com/watch?v=9vPUMe3lzfo. The experience on Jenkins-ci.org should be at least as rich as the in product experience. Ideally, the categorizations should match as well so that it is clear to both users and plugin authors how we are dividing the universe of plugins.
In addition to the Jenkins bits themselves, the plugins give the Jenkins-ci.org website a level of draw and value that exceeds that of a normal content website and as a result, I think it makes sense to emphasize enhancements to the plugin management area of jenkins-ci.org as a priority over other content types. It in particular has the potential to sing and attract site visitors on an extended and recurring basis.
Other content types
Ideally, event handling and documentation should receive some love as well. For events, the current site has an embedded Google calendar which has some upside, but does little to enabling the 'featuring' of events and the relating of particular articles to events. As an example, I have recently done a webinar on the Jenkins GUI. I have the video recording, a list of questions and answers, a (not yet written blog post) and an additional video to go along with the event. I did not succeed in getting the event on the calendar, but even if I had, I don't have a good way to relate my additional materials to that event. The event was mentioned as a 'news item', but again, no means to relate this additional material to that articles and that news post did not tie into the calendar as one might expect.
Documentation is also a little difficult to decipher on the existing site. I am assuming this is its table of contents: https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins.
In a sense, this is fine. Documentation does need as much visitor interaction as a blog post or plugins to stay pertinent, perhaps, but the fact that it is masked under the name of the delivery tool, WIKI, rather than its subject matter makes it hard to find. Additionally, the form factor of the display of the doc matches the form fact of the news item display. The news items are essential junk content of relatively less lasting value. When I look at documentation, I do want to get the sense that it is timely, but I don't want to mistake it as the sort of casual, 'hey, what's happening' content of some of the rest of the site. I want to feel like it is an official answer to whatever my question is. Likely the enhancement to this content area isn't so much technical, but aesthetic; though it does need to be discretely searchable. Also, the doc needs to be a little more complete.
Featured content and a dynamic browsing experience
Independent of the form factor of a particular piece of content (doc vs blog vs event vs plugin) and even its subject matter (mobile development vs workflow vs GUI vs Getting started), it is important that pieces of content be elevatable to some form of promoted status. This is particularly important when welcoming wide audience participation. The site curators will still need some levers of control to place emphasis on the material that is mostly likely to draw eyeballs or deemed to be of greatest value to the community. As an example, many events happen in the Jenkins community: my recent webinar, office hours, and JUC events. As JUC events draw near, the have a level of importance that is greater than other events. Similarly, as LTS events approach, they have a growing degree of prominence. For plugins, it is highly likely that some editorial oversight will be beneficial to the community. Rather than exclude content as a means maintaining manageability, my inclination would be to collect and publish as much as possible. But, to avoid losing the gems in a sea of salt, it is nice to be able to elevate the good stuff.
Rich metadata for the site visitor
In the ideal world, content is added to the site frequently and by diverse participants. This requires that content authors enjoy a considerable amount of autonomy in their work. For a compelling site, however, it is similarly important that site visitors have a coherent experience when moving from article to article and an intelligible and predictable means of finding those articles that relate to their needs. In general site building, this requires site curation by an individual or individuals monitoring site traffic and ensuring that related articles are grouped together and site goals are being met. This can either mean hand maintaining a set of template static wrappers, hand construction of topical junction or linking pages, or by strategic application of metadata to content and careful modeling of that metadata into a site structure. At smaller scales, the hand creation of static material tends to have more appeal to end users, but at larger scales hand curated material tends to become stale, disjointed, or completely unmaintainable. I believe Jenkins-ci.org is already of a sufficent size that hand maintenence will be difficult and metadata modeling will be beneficial. My hope is that the site will enjoy accelerated grown in its new encarnation. Thus, I am fan of rich content metadata.
Relating content by author is a relatively easy bit of metadata to add and its validity can easily be enforced at creation time. Thus not only does an emphasis on the content author reward the author, it also rewards the reader, as it makes it easy to find articles that share a common, intelligent author. In the ideal case, this becomes a virtuous cycle.
