Posted by leisareichelt on March 30, 2011 at 12:51pm
I think we've touched occasionally on the idea of a 'topic' page - a way to get a slice of the issue queue across a particular topic (I'm using this in place of tag at the moment... partly because I want to avoid the issue of legacy tags right now. we can get to that later).
this would be a place where you can both get an overview of D.O activity relevant to the topic and to be able to follow that topic for future notifications etc.
I've done a really rough wireframe of what might go on there - lots of detail yet to be added.
thoughts/feedback/ideas welcome.
https://disambiguity.notableapp.com/posts/ff94db8fa646f9d6023f6e63eedcd5...
Comments
Seems like a potentially
Seems like a potentially useful place for a multi-value node reference field? The [#NNNN] filtering is annoying me recently since the filter cache holds the result and issue status doesn't get updated.
Very cryptic :)
The [#NNNN] filtering = Project issue numbers (ex. type [#12345]) turn into links automatically like so:
Multi-value node reference field = a way to enter those #12345 numbers in a textfield of an issue and it will create a reference (link) between this and that issue. (right? :-)
I think the question here is how we can let hot topics bubble up somewhere. Say, the issue tag 'Performance' has been trending, with multiple issues being tagged with it recently. Probably means that this is an active topic. Now, what can we do to show that trend outside the issue queue so that people who are not yet working the queues yet can get an idea of what is going on and find a place to dive into a topic that interests them.
Thanks for the clarification
I've been having a hard time figuring out how to dive into the Prarie initiative, which was puzzling to me as I'm enthusiastically supportive of the idea. The first thing to draw me in was pwolanin's suggestion to use multi-value node references because the [#NNNN] notation is such a huge pain point for me personally. The exchange which followed it helped me realize why I haven't been able to find an entry point ... I have a different set of priorities in my head based on what I think the purpose of the issue queue really is, and it makes me organize things quite differently.
To me:
-- project maintainer/s and project users
-- project maintainer/s and co-maintainers
Ensuring the quality of this communication is the highest priority. Things like how long it took me to learn that the [#NNNNN] notation even existed and then come to terms with how its belated updating undermined its value count as high priority in this category from my perspective.
The user story yoroy is describing is so far out of my experience and there are so many substantial problems that I prioritize ahead of that story it would never occur to me that a Topic page would focused in that way.
Now that I realize this, I can look over the topics and see better where to get involved.
huh?
I'm still a bit lost on the multi-value node thingy but agree that ability to let 'hot topics' bubble up is a good one.
This fits into the whole piece of work we need to do on discoverability.
leisa reichelt - disambiguity.com
@leisa
multi-value node reference vs. [#nnn] notation vs. topic pages
I'll try to explain...
Currently, one way to reference another issue while commenting or composing your own is to find the issue's nid and type
[#1233456]into the text, and it automatically turns into a link to the issue. There are a bunch of drawbacks pwolanin, eliza411, and yoroy are all pointing out, which I completely agree with. In places where you want to manually point to other issues, a first-class node reference field would be a lot more powerful, and hopefully much easier to use than the hidden/cryptic inline text notation.I believe that pwolanin is suggesting that on the topic page itself, instead of using this same [#nnn] notation inside the #2 description field, there would be a separate node reference field to point to related issues. This separate field would have a small handful of text boxes to start, and you could keep adding more if you needed to.
However, I think that overlooks the wider point of the whole topic page -- to automatically aggregate all issues (and other content, for that matter) tagged with the given topic. So, in this case, I'm really not sure the value of this multi-valued node reference field. Certainly issues themselves should have them. But I don't think topic pages need them.
... vs. hot topics
p.s. While I agree some functionality around "hot topics" could be helpful and cool, neither the [#nnn] notation nor a multi-valued node reference for issues to point to each other is going to tell us anything about what topics are hot. For that, we need to look at the links between topics and issues, and between topics and other topics...
I really like the idea of
I really like the idea of gathering different activities around specific topic in one place. With possibility to get aggregated updates on this topic.
What I am a bit concerned is the number of different places where some activity is going on and where you can possibly find some information, amounts of duplications of activites/information. We have currently issue queue and forums and groups and irc. And you just need to follow so many different sources to keep up-to-date. I think the goal should be in reducing the number of this places, making less of them but more useful. The great initiative is going on with sort of Q&A site support.drupal.org. This could possibly eliminate forums for good.
Now this long intro was for a vague idea I got. Could we maybe somehow merge this topic idea with groups?
Just a vague idea, probably won't be good for all the cases (for example, for groups like "Drupal users of XXXX country"), but still something to think about.
"The great initiative is
"The great initiative is going on with sort of Q&A site support.drupal.org."
We don't intend to get rid of forums, just remove the support aspect from them so they aren't cluttering normal discussion. Though you raise an interesting point. If forums are down to just discussion, isn't much of that mimicked in g.d.o? We do have a blurry line between groups and forums. Much of what is in groups should probably be in forums and vice versa. It gets confusing. And I am all aboard the "g.d.o is not easy to navigate" train.
topics *and* projects as groups
I agree that more things on d.o need to behave as first-class groups. I've long advocated for having every project node on d.o configured as an organic group. However, the idea of also making the topics themselves groups is fascinating. Very cool!
I think we should try to get OG to a point where you can deploy a light-weight core of it that does no node access on its own (basically, move all the node access parts of OG into a separate module included in the same project) and deploy it on d.o. At least for projects. If we have these topic home pages, make those groups, too. Community initiative book pages while we're at it! ;)
There probably are some good reasons to keep a separate "groups" site, too, but that's certainly not the only place that we have groups of users that need to get notified about shared stuff. And the navigation is definitely going to get better once g.d.o is finally migrated to the bluecheese theme as part of the *.d.o redesign -- once that happens it'll be a lot more integrated and consistent with the rest of the subsites.
Forums verse Groups
Forums are a way to assign content to a pre-defined topic list, they are maintained by the site staff, and are moderated by the site staff. The Site Staff determines the forum scope.
Groups however are moderated by the sites users. Part of the problem that continues to be brought up is How to meet the content desires of an audience. Well Isn't an audience the group, and isn't the content what ever you put in the group? So when people talk about creating content for developers, then isn't what they want is a group called "developers" and to be able to assign the content they find useful to that group?
I have seen the benefits of a Group over the Forum are that their is ALLOT less trolling going on in Groups. In addition, groups are built and promoted by the creators of the group. Groups that are not moderated and are not promoted die a slow painful death.
Overall site Moderation is also reduced by Groups, since each group has its own moderators.
Also this caught my eye http://drupal.org/project/noderelationships
--Sig--
Owner of Proper Programming, LLC a software and website development firm.
Feedback on the topic page itself: love it!
In my other replies in here, I forgot to mention my general feedback on the proposal for topic pages itself ...
I love it! This looks super cool. I wish we had this now. There's definitely nothing on your mock-up I'd take away. The only thing I'd add is making related topics nice and visible (if they've been defined). I'm sure I'll have opinions on what the table of the issues themselves should look like, but those details aren't the interesting things about your mockup (which is why you didn't spend any time on them). ;)
I have a lot of ideas about how to implement this. Not sure if this comment is an appropriate place to start that discussion. ;) But, brief summary of my proposal for interested parties:
- Create a new "Topic" node type on d.o.
- Give topics a "parent topic" node reference (could be single value if we need a tree, or multi-value if we can handle a DAG).
- Give topics a "related topic" multi-valued node reference. We'll compute and display "blood relatives" automatically, so this would only be for pointing to other branches of the graph (tree?) under different ancestors. I'm not sure we need this, and it might make things confusing, so perhaps we can get everything we need from a single (or few) parents and display all the relationships based on that. However, I don't think most topics will have a parent defined, and yet other topics will still want to link to them (perhaps as the first step towards discovering that you want a parent topic for both of them). So, I believe we should give topics friends, not just family. ;)
- Give all issues, book pages, forum posts, and anything else we care about a multi-valued "topic" node reference field so they can be tagged with topics. Of course, it'd be nice if you could update this reference just by commenting on something, and/or maybe via a flagging approach without a comment at all (especially on book pages once they no longer allow comments).
- Do something smart with following and notifications, perhaps by configuring topic nodes as OGs (see above).
That should basically do it. The main tricky part is the following and notifications aspect -- which of course is a huge part of what would make all of this so useful if it all Just Worked(tm)...