Page Comparison

Using the creation date for News items would work for ordering news items in most instances, however, using a modification date might make sense. There are some news items which needed to be weighted such that they appear on top of the list and stay on top. For example, the annual conference announcement might appear for several months and becomes more significant as the conference date approaches. Similarly, setting an "expires on" date would be useful. News items which describe an event which happened in the past, in many cases, is of little use. For example, "uPortal Training to be held March 1st" is of no use today (March 4th).

How should "events" which are also "news" be handled? Events would always have a date associated with them but might also be considered "News". Do we some sort of informal policy or criteria for determining where items appear?

Jonathan Markow:  Right now, the wiki provides the list of members.  That's probably because it was easier for me to update it there.  I'd like to see it on the website but eliminate the redundancy in the wiki.  Similarly, there is a Governance space on the wiki that lists the information that's mentioned in the previous requirement.  Once again, we need to ensure that we don't create redundant lists and other info.

~awp9 wonders whether these instructions should be out of scope for the website itself. While it is important at a marketing level that it be clear that one can birth a new project, doing so is relatively infrequent, relatively technical, and needs to be kept up to date. It more fluidly connects with the collaboration happening in the wiki than with the static statements of the website. ~awp9's gut reaction is that the website page should be just a stub that links out to what we regard as more wiki than website.

~jayshao argues that a reasonably fluid system for manipulating the website results in a dynamic where location of content is less influenced by how often it changes, and more appropriate to determine based on whether or not it's a collaboratively edited document - as some "official" content is probably better suited to basically a broadcast approach.

Jonathan Markow sez:   Website = Identity, brand, information, marketing, communication outside JASIG, easy answers to frequently asked questions.  Wiki = Collaboration, projects, work-in-progress, documentation.

~jayshao my point being that's an artificial technology driven distinction, instead of an intention-based decision. Providing polished, external consumption vs. working internal consumption is a reasonable distinction. Basing that division on the technology we use to deliver sites seems less meaningful. It is possible to restrict & top-down IA a site in a wiki, just as it's possible to have a non-IA site in any CMS or HTML construction. The question is what roles do we need to fulfill?

Jonathan:  We should have a page about JA-SIG projects a la Gary Schwartz's suggestion below.  Not "how to birth", just something about what it means to be a project. 

Aaron Godert and Jonathan Markow have withdrawn this item for further consideration. Not for initial inclusion in revitalized website.

(Interestingly, uPortal's developer books channel, once upon a time, did this, with the kickbacks going to IBS for a few minutes. The kickback feature was removed at the project administrator's request. -~awp9)

~jayshao I also put this in the category of "unlikely to generate enough revenue to be worth it". The idea of a virtual professional reading club is perhaps very attractive - pick a technical book (DDD, Effective Java, GoF Patterns, etc.) and have a themed discussion on a mailing list or in IRC. That seems to better build us as a community of practice and support our professional development and networking missions much more strongly than a passive list of books. In general, I think any linkages we can build between in-person events will only strengthen our community.

~awp9 I agree, Jason. If social networking around books in JASIG is worth doing, then let's set up a JA-SIG Goodreads group and jump to the part where we share book recommendations and discussions, and skip the part where we expend limited JA-SIG infrastructure and website resources on implementing Amazon's referral mechanism on jasig.org's web presence. Prioritizing the most important, and achievable, web presence requirements, like timely presentation on the JA-SIG homepage of JA-SIG conference calls for proposals and seminar selections, is important to the success of this webpresence revitalization effort.

Jonathan Markow sez:   I will withdraw this requirement on the basis of "not enough bang for the web-redesign buck."  On the other hand, I would like to see us provide a list of recommended books/tools/etc. *somewhere* that would be useful to newcomers to the community.