Group relations: Difference between revisions
mNo edit summary |
mNo edit summary |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
{{TOCright}} | {{TOCright}} | ||
{{eyecatch|Important notes| | |||
{{eyecatch|Important notes | |||
*The type of relation that can be added to a group is constrained by the type of the group. Only ''virtual groups'' may have joint relations, only ''non-virtual groups'' the other types. | *The type of relation that can be added to a group is constrained by the type of the group. Only ''virtual groups'' may have joint relations, only ''non-virtual groups'' the other types. | ||
*A virtual group is not really a group but ''a representation of a joint project'' (or several) between one or more groups. Some virtual groups may have only one parent, in which case means that one of the parts is so unimportant by itself that no group entry exists for it. (Could be that the group has never released anything independently.) | *A virtual group is not really a group but ''a representation of a joint project'' (or several) between one or more groups. Some virtual groups may have only one parent, in which case means that one of the parts is so unimportant by itself that no group entry exists for it. (Could be that the group has never released anything independently.) | ||
*Relations are ''directional'' and only ''one-way'' adding/editing is supported by the interface ( | *Relations are ''directional'' and only ''one-way'' adding/editing is supported by the interface (ATM). This means that if you want to add a joint relation, for example, you have to add it to/from the virtual group; it is not possible to add it to/from the participating groups. The group relation page (addgroupgroup) will redirect you to the other end of the relation when it is necessary.}} | ||
==Types== | ==Types== | ||
Feel free to suggest changes to the description texts and labels. At least the labels on the group page are not very clear | Feel free to suggest changes to the description texts and labels. At least the labels on the group page are not very clear ATM. | ||
===Joint=== | ===Joint=== | ||
Line 64: | Line 63: | ||
* Expand by group should list the same files as the anime-group page does, maybe. | * Expand by group should list the same files as the anime-group page does, maybe. | ||
* Group box @ anime page should group joints together, maybe. | * Group box @ anime page should group joints together, maybe. | ||
* Better representation of | * Better representation of MyList state @ anime-group box and group page. | ||
* Completion bars at group page. | * Completion bars at group page. | ||
===Rights=== | ===Rights=== | ||
Normal users have the right to add relations | Normal users have the right to add relations ATM. The only problematic relation is ''joint'' (since it affects group stats and anime-group relations so much), but since this relation is constrained by the group type it shouldn't be much of a problem. The user have to creq the group type first anyway. The other types have no real meaning (at least not yet) and should therefore not be much of a problem either. | ||
[[Category:Development]] | [[Category:Development]] |
Latest revision as of 14:44, 24 April 2009
Important notes |
|
Types
Feel free to suggest changes to the description texts and labels. At least the labels on the group page are not very clear ATM.
Joint
This group includes the other group. ANBU-AonE -> ANBU
Joint - Participant
This is the most important type of relation because it affects different stats and listings. Using the example group ANBU-AonE:
- All stat counters (number of anime/eps/files) and total file size for ANBU will include the files by ANBU-AonE. The same is true for AonE. The stats for ANBU-AonE will of course not include files by released separately by ANBU and AonE.
- The anime-group page will list files in the same manner. Naruto-AonE will list the Naruto files by ANBU-AonE and AonE. Naruto-ANBU-AonE will only list Naruto files by ANBU-AonE.
- The anime-group status, found in the anime and group pages, will reflect the relation likewise. Naruto-AonE has the state completed while Naruto-ANBU-AonE is dropped. The status of the participating groups should not be dropped unless it is clear that they will never continue in any other form. Inukami-Mendoi-SHS-KAA is an other example of such cases.
- The group page will list all releases by a the group + releases by joint projects. An anime entry will only appear once, though.
Important | Only groups marked virtual/joint can have "joint" relations. It is the only relation type such groups can have. |
Child/sub/branch
This group is a child of the other group. DB-BR -> DB
Child - Parent
Split/fission
This group split from the other group. Conclave -> A-Keep
Split - Lost
Merge/fusion
This group merged into the other group.
Merge - Merge
This should not be used between the groups that merged, but between each part and the new group.
Rename
This group was formerly known as the other group.
Formerly - Now
Other
This group has some other weak relation to the other group.
Other - Other
Used for loose/weak relations between groups. It should however only be used for real (official) relations and not just for "fun".
Suggestions
Interface
- Allow adding both ways.
- Better descriptions and labels.
- Latest relations.
- Filters.
- Reports.
- Better representation @ group page, a new box only for relations so the info box don't get too big. This problem exists for the anime page (anime relations) too.
- Group relation maps?
Related:
- Expand by group should list the same files as the anime-group page does, maybe.
- Group box @ anime page should group joints together, maybe.
- Better representation of MyList state @ anime-group box and group page.
- Completion bars at group page.
Rights
Normal users have the right to add relations ATM. The only problematic relation is joint (since it affects group stats and anime-group relations so much), but since this relation is constrained by the group type it shouldn't be much of a problem. The user have to creq the group type first anyway. The other types have no real meaning (at least not yet) and should therefore not be much of a problem either.