The DrupalEd project is now live on Drupal.org -- we are now ready to use the issue queue to centralize discussion on the different install profiles. In starting to discuss the profiles, I suggest we use the following format, as we will need to answer these questions as we build the various profiles.
- Site Description: the functionality/use case for the site (and we have started on the descriptions in the various site descriptions in this wiki page).
- Roles: the various user roles, and brief explanations of how they will function if this is not self explanatory
- Content Types: the different content types in use on the site, and the roles that will be able to access them
- Install Process: the install profile will lay out different options -- what do we want the options to be? We can also use the steps of the install profile to deliver training/documentation on how to use the site. While I don't want to get overly laborious with this section, this is also a possibility to document how the site works, and relay that info to the end user
- Module List: What core modules will be turned on, and what contrib modules will be added?
For future iterations of these profiles, I think we should make some options within the profile for block and menu variations, but for the first pass I suggest we set up some sensible defaults.
So, let's create some profiles and make this happen.
1. School Portal
A place for a public-facing web presence for a school. This will be the most simple profile and will look like a very generic Drupal installation with content types "story" and "page" and a couple of default pages and settings: "Welcome", "About us", "Contact".
2. Academic Department
A site that provides an overview of an academic department in higher education. This looks a lot like the School portal but will have more default pages, including for instance the different faculties and educations, and some default "views" to list them all.
3. One teacher, one or multiple classes
One teacher providing all information to the different classes. This is a very simple version since the roles are easy to distribute: there's one "moderator" namely the teacher and all other users have the "student" role in succession to their class role. Using taxonomy_access each piece of content will have it's own tag/class that only those students can see, next to a "protected" tag so that any student can see the content and a "public" tag for anyone (not logged in) to see. A group can be created per class, as well as a "student group" for the pupils to gather and discuss. A forum should probably be set up with some default categories.
4. Social Learning Space
A site where teachers can manage blog-based classes, teachers and students can create working groups, with support for multiple content types broken out by role -- the current DrupalEd install is a middle ground for this type of profile. This is the largest set-up and will need a great deal of consideration about the whats and hows.
5. Research Space
A site that supports modules and plugins that collect and analyze data, and publish the results. This could include elements such as polls, quizzes and views of web stats, and possibly support integration with research tools such as libsna, and reporting & visualization tools such as pentaho? A note to consider: since those products are open-source but not GPL, we will not be able to include them with the distrubtion, forcing users to download and install them manually. This should clearly be advertised on installation.
Next steps
Over the next few days, I'll create a project on d.o for DrupalEd -- I'll post here when it's live, and then we'll have a central place to discuss and manage version control of different profiles. ~billfitzgerald
Comments and thanks
Thanks Bill. The project space will definitely help with this endeavor. Not sure what happened with the Organic Groups Drupal Ed thing. That looked cool. In looking at my school district, I think they would be better off offering teachers their own space for each teacher to create their own groups - one group per class. I've got that setup pretty easily but haven't figured out the grading and tracking homework part. As student login, they can view their grades and homework assignments. In the meantime, each class (which is an organic group) would be it's own portal or blog. That way the student has a list of classes (portal/blog) that he/she can go to in order to discuss assignments or get help. That is how my on-line schooling is setup at Western Governor's University and it is pretty effective (other than using a mangled Oracle portal product). ~harriska2
I removed the "One teacher, one class" since this is just a simple form of the "many classes", no special options are needed. I sorted them in order of simplicity ASC. I'm very happy with these categories: they are easy to understand and very flexible. Good work Bill! ~wmostrey
DrupalEd Rocks! Thanks to all involved. I added research #5 above. ~ethang
All of these are wonderful ideas, and I can think of several ways to use each profile type. Everyone working on this project is amazing and I am grateful for the work Bill and others put in. When it comes to my primary needs, the public-facing portal, I don't think we should be quick to assume too much simplicity.
I'm currently working on replacing the public-facing site for a small college and need a lot more than is detailed here. Many smaller schools (2000 and fewer students) have a unified site rather than seperate departmental sites, so I want to be able to do hierarchical pages with lots of different content elements. Also, moderation is a big deal since 30 people from around campus (many of whom managed to get Ph.D.s without learning to punctuate) update content regularly, so we need workflow and moderation that's flexible to some extent but, most importantly, just works. Also, a well thought out personnel directory is incredibly important for the public. Our particular plan calls for the personnel directory to link to a bio page the employees can update themselves and also allow them each to maintain their own blogs. Likewise, we plan on having each standing committee and student club have their own group with both public and private content including calendars that get aggregated into one comprehensive campus calendar and event list.
In other words, in order to make the site truly useful and appealling to both internal and external audiences, we need more than simple "about" pages on the public-facing portal.
I'm not saying the group has to scratch my itch, especially since I'm a writer/editor/PR person with a Web site in my charge rather than a real developer who can contribute much besides ideas. But, I have a feeling a lot of organizations, whether academic, non-profit or mid-sized business, would find an install profile that does what I've detailed incredibly appealing. ~Scott (sacushman)