Forum .LRN Q&A: Re: Nominclature Cleanup

Collapse
10: Re: Nominclature Cleanup (response to 1)
Posted by Carl Robert Blesius on
Modified version with html models:
  • 1. (now) GROUPS
    • Classes (w/ subgroups)
    • Communities (w/ subgroups)
    • 2. GROUPS
      • Classes (w/ sections)
      • Communities (w/ subcommunities)
      • 3. COMMUNITIES
        • Classes (w/ sections)
        • Groups (w/ subgroups)

        Webster Online : sub·com·mu·ni·ty
        Function: noun
        : a distinct grouping within a community

        Webster Online : sec·tion
        Function: noun
        11 a: one of the classes formed by dividing the students taking a course b: one of the discussion groups into which a conference or organization is divided

        We just need something that makes sense for the standard install. If section doesn't work for an institution there needs to be a site_wide_pretty_name_parameter in addition to the one that a course administrator can set.

        Subject=Class at MIT? That would be quite atypical. In dotLRN a subject is just a way of grouping classes.

        ---

        Wow I just got stuck in a "group loop". I just added a subgroup to a subgroup to a subgroup to a subgroup of a class and started to get dizzy.

        Fixing up 1 would be the easiest solution (EVERYTHING is a group and EVERYTHING can have subgroups). We will just have to worry about cleaning up various strings to reflect this.

        It needs to be clear that these ARE the key terms in dotLRN. These terms are what dotLRN is about and they need to be as clear (and general) as possible. If we do not have a clean nomenclature in this area we will add confusion to the dizziness caused by the infinite number of "subgroups" possible.

        This might be a factor when we start to think about how to add additional organizational units to dotLRN 1.1 -> we will need more ways of "grouping groups" than just departments and subjects (which at the moment are not actual groups in the subsite sense) and we will need to bind certain roles to these groupings (e.g. departmental administrator can administer classes in a specific department... or faculty). The question is if we use the grouping structures already possible in dotLRN or think of something else. We need to start talking about this as soon as we solidify the 1.0 release (it is getting harder to find people willing to contribute funds for the second version of a product when the first version isn't even out the door).

        So what is it going to be: 1, 2, or 3? We need to know so we can start posting bugs and patches for these changes. The optimal window for the dotLRN 1.0 launch is approaching fast.