Current Status - Ready for implementation
The design phase is over for this sub-project and it is ready to be implemented.
Discussion on technical implementation started here: http://groups.drupal.org/node/179394
Overview :
'Topic' page aggregates all activity across d.o, which was tagged with this specific topic.
We've explored and ditched the idea of these things being 'team' spaces.
Earlier Prairie discussions
- a topic page, initial ideas - http://groups.drupal.org/node/138439
Purpose
The purpose of the 'topics' is multiple including:
- a way for people to identify their expertise
- a way to aggregate content of interest to that topic from across Drupal.org
- a way to see what is happening around specific topic right now, where and who is active
- a way to aggregate people who have interest/expertise into one place so that they are contactable en masse (when their assistance is required)
- a way for people to find mentors/people with common interest more easily when they join our community.
Mock-up:
More images and detailed description can be found here: http://groups.drupal.org/node/144584#comment-592174
Description
There will be 2 types of topic pages.
1st there will be short list of "top level topics" - most general ones. They will have path aliases drupal.org/usability etc. Only webmasters or some other users with special permissions will be able to create these topics.
Then there will be "usual" topic pages - subtopics, more specific than top level ones. This pages will be "childs" to top level topic pages. All drupal.org users can create subtopics of any depth.
When creating new topic - user can choose any existing topic(s) as parent(s) and as subtopic(s). Topic can have no sub-topics but should have at least 1 parent.
Topic pages are wiki-like in that their titles and descriptions can be edited by any follower of the topic (with a revision history kept).
Topic pages will have links to show a view of issues, groups, documents, discussions, initiatives that have been associated with this topic.
Main part of topic page - aggregated 'latest activity' across a range of content types on the site with ability to filter for a particular type of content (eg. issues, groups etc.)
RHS column allows you to:
- follow topic
- change notification settings
- see the number of topic followers as a link to a page showing followers list
- share/invite: this might be a share link on Twitter/Facebook or a form to invite other people on D.O and the rest of the world to come join the topic
- view FAQ/summary or links where we can get newcomers across the history, background, whatever is relevant to get them up to speed quickly.
- see most active topic members (based on their activity across all the aggregated content on the site - more scalable/friendly than 'maintainer' links but would presumably still show the maintainers here because they're most likely to be v active)
- see important links - links to key groups/documents etc. where people in this topic are active.
- see parent and sub-topics of the current one
- related topics - links to other teams that members of this topic are most likely to also have an interest in. This is human editable.
Proposed list for "top level" topic pages
We need to define a list of (ideally) less than 20 teams to begin with.
Here's a starting point for discussion/building out. The fewer of these we have to begin with the better. Probably.
- Development
- Design & UX
- Theming
- Documentation
- Translation
- Marketing
- Learning Drupal
- Accessibility
- Security
- Support
- Performance
- Newcomers
- Drupal.org (webmasters on d.o, g.d.o, infrastructure team)
- Git
| Attachment | Size |
|---|---|
| Drupal-team-taxonomy.xls | 40.5 KB |
| TopicV2a.jpg | 67.65 KB |
| TopicV3.jpg | 71.77 KB |
| TopicV3b.jpg | 94.49 KB |
| topic_pagev10a.png | 181.53 KB |
| topic_pagev10b.png | 188.32 KB |
| followers.png | 205.61 KB |
| Important-links-edit.png | 22.36 KB |
| Invite-users.png | 3.95 KB |
| follow-button-states.png | 11.35 KB |
| Add-parent.png | 2 KB |
Comments
As compared to g.d.o
Hi. Awesome work on this. I just wanted to point to the newly reworked Code Review g.d.o group: http://groups.drupal.org/code-review
My goal with it was to create a space that was focused on team building. I don't think it's perfect or anything, but it might be good inspiration.
I am curious, as is the difference between a "Team" as described here and a g.d.o group? And why shouldn't g.d.o be outfitted with these features instead? I can see the difference, but it this seems like a core function of groups. Maybe I am also curious on how "Teams" are defined and why.
--
zzolo
for meta-issue collaboration
The "team" concept grow out of an earlier discussion on creating "topic pages". That idea (and this one) is an attempt to provide a single "space" within the *.drupal.org ecosystem where people interested in a broad topic or initiative can track and participate in the many varied activity around that topic/initiative whether in issue queues, documentation pages, or associated groups.
Or in other words, it provides an activity stream or news feed to track a particular subset of activity on the *.drupal.org sites.
And if I understand Leisa's intentions correctly, "teams" won't provide any new ways to discuss or collaborate, they're merely a way to aggregate activity and provide a way for discovering who has expertise (or at least is interested in helping) in different areas.
Also if you look closely at the mockup, it has a tab for groups associated with this team and also one of the updates listed there is a comment from the Prairie Initiative group.
So I don't see much overlap / competition between groups and teams.
In your case, with the code-review group. You'd be able to create a "code review team" which could aggregate all issues tagged with "code review" as well as discussions from your group as well as updates to pages documenting how to do code reviews. Then people interested in doing code reviews (and perhaps receiving code reviews) could join the code review team and follow activity and requests for help that way.
Kyle Mathews
Team list
Can't really tell why but "Learning Drupal & Support" does not sound quite right. Maybe because its either team of people who learn drupal or team of people who know it good already and provide support?
Community Management - not really clear what kind of issues/groups etc. it will aggregate. Is it like for webmasters issue queue and g.d.o maintainers? or something else? Plus lets please not name it "cat herding". Doesn't look good in context "N member of cat herding team" or issues tagged "cat herding".
And why did you decide to move Design & UX together? There in excel file I saw "Design & theme" and "UX & usability", wouldn't it be better choice?
re: Team list
yeah, I'm also inclined to separate Learning and Support into two teams, esp after feedback I got from the survey we're running. The idea of 'learning' was more about Drupal Education, people who are teaching other people how to use Drupal. Support is more self evident I think.
community management is probably more than a stub (and yes, cat herding was not a serious suggestion, perhaps I'll edit that out ;) or you're welcome to!). The kinds of things i was thinking of for Community Management was for people doing code review, people talking about leadership in the community... and other kinds of issues that are more about the ongoing health and growth of the Drupal community.
Design & UX I put together because... I think they go together (or at least they should!) - this might be an overly personal mission but I'd love us to stop talking about 'usability' (which implies testing other people's work and telling them what they've gotten wrong) and start talking about User Experience, which is more holistic and involves designing the experience up front and being part of the solution development, not the police at the end of the process....
Just my thoughts tho'. I'm sure there is plenty of work we need to do on this list!
leisa reichelt - disambiguity.com
@leisa
I agree that the word "team"
I agree that the word "team" is confusing things. It implies there is activity and work being done, and makes it sound like a drupal group or something like the Docs Team. I don't want to be on a ecommerce team, but I might want to follow the topic."Topic" or "Category" or something else would make my brain less confused.
Something in between...
yeah, we started off with these being called 'topic pages' but as others pointed out to me, 'topic' and 'category' sound so very mechanical and not very human. I agree that team is probably a little too far in the opposite direction, with the implications you suggest...
what something that is more 'human' and engaging than 'topic/category/team' and less activity implying than 'team'?
one of my other working titles was 'sub-cultures', which I kind if like but suspect it might be polarising... or maybe just a bit silly. what do you think?
I'd definitely associate myself with a UX/Design/etc. subculture. Not sure it works quite so well for eCommerce, Security (actually... a security subculture sounds kind of sexy), Performance...?
anyone got a thesaurus handy?
(obviously groups is out too otherwise we enter a world of confusion).
leisa reichelt - disambiguity.com
@leisa
Some brainstorming
Here's some other ideas for names. Some better than others.
interest, cause, pattern, initiative, attractor (from chaos theory), unit, tribe, meta-issue, switch, router, manifold, activity board, bulletin board, stream, feed, river, creek, organizer, counsel, committee, network, flow, emergents
Kyle Mathews
Initiative
I really think Initiative is good, but not sure if this idea is replacing Community Initiatives already started (though I think it should be).
--
zzolo
complementary not competitng
Community initiatives and [whatever we call this] are complementary efforts not competing. I'm sure the community initiatives will make heavy use of these pages for coordinating their efforts. Calling these pages "initiatives" would just introduce confusion as they serve somewhat different ends. These pages are solely for coordinating, community initiatives are for setting blessed roadmaps.
Kyle Mathews
Aggregation of content, not people
I've been casually following this, and was a bit thrown when I saw the term "team" appear. This idea appeals to me on the basis of aggregating data over users. From that perspective "topic" seems entirely appropriate.
"Topic" isn't especially human or welcoming, but it offers great continuity all the way from the origin group where content is tagged or labeled to the page where it's collected. There are options like those Kyle pointed out, plus softer terms like "hub", but I feel the content is the guest of honor here, not the followers.
A nagging concern in the back of my head is "Sure, it's great to not have to join/follow 6 groups, but is this meta stream going to be of widely varying relevance/value?"
My G.D.O digest is already incredibly dense (and inscrutable) - while individual group messages are a hassle, they also provide an opportunity for triage based on the group they're in.
agreed
There will (and already is) be a lot of confusion between "groups" and "teams". I'd rather keep them as "topic" pages.
One other (potential) problem. Calling them a "team" implies that someone needs to manually create this "team" and should be actively leading and managing "team members". I'd prefer a system where we create upfront a huge list of "topics" to start things off but then anyone who feels like it can create a topic or sub-topic on any number of things.
There would of course need to be a "team" (hehe) that manages the topics to keep them semi-coherent but I think the "let a thousand flowers bloom" model works better here than trying to create a nice manicured garden.
Kyle Mathews
topic +1, team -1
I loved this when my mental model was that these are "topics" which span lots of different kinds of content. Now that it's moving towards "teams", I'm having more resistance to it. Too confusing with groups, too much baggage with what makes a "team", being a "good team player", etc, etc. I thought this whole thing was to have a better tool for tagging things with topics so that people who care about a given topic have a better chance of finding things related to that topic than trying to follow N different issues queues + M different g.d.o groups. Basically, issue tagging with much more power and flexibility. The more this becomes a "team" that I "join", the less valuable it seems to me. The more this is a "topic" I can "follow", the better. If you haven't already, you can read my previous thoughts on the proposal.
That said, I can see you're also trying to solve the "what things is user N an expert in?" problem with this same plumbing. That's not necessarily a bad idea, but my sense is we're trying to look at the implementation and solutions a little too closely and that's clouding our image of what the interface and experience of using this system would be. Maybe that's just my own bias, but it seems like this is already taking shape as a "solution" to two problems that might not necessarily want the same solutions. ;)
I agree. Topic is fine. This
I agree. Topic is fine. This is something mechanical. I would want to follow, or even just look in on, a topic. "Channel" might also be ok. Then you can say things like, "Check out the Security channel for...".
expertise scoring secondary
I definitely agree that the expertise/reputation scoring stuff should be secondary. If there's any compromise that need to be made in the design between the activity stream stuff and the reputation stuff it should definitely come at the expense of the reputation stuff. Regardless of how much fancy analytics we do to bubble up the "best" or most "prolific" contributors, the most important reputation analysis tool will always be our heads.
But having said that, I think having a "most active" block and perhaps a "top committer" block makes a lot of sense for these pages.
Kyle Mathews
Topics indeed
The team building is more something we want to stimulate happening and maybe not be so explicit about. I do believe that it would be beneficial to have maintainers, existing teams and related groups offered for context and clarity (wouldn't want to not mention the security team on the security topic page, right?). Same for Big Initiatives within the topic.
Simplistic wireframe of the things I'd like to see pulled together here:
This looks great!
I look forward to seeing this implemented. I like how you've broken down the different blocks of content.
It does matter what we call these new entities, but I don't have strong opinions about that.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
yoroy +1
aha, this is giving an idea.
Leisa largely implements tabs to keep things clean. I guess for details you are also planning on this ;)
A general UX pattern for tabs could be that bigger areas (you put boxes around them) also get a tab for more details on the given subsection.
Life is a journey, not a destination
Participate?
How about "I want to participate" or "I want to contribute" or "Get Involved"?
-1 topic
-1 team
--Ryan
Ryan Cross
Drupal Development Services
ProjectPier project management and collaboration software
Meta-groups
Also, just reading through more of this discussion it sounds like this could be some sort of "meta-group" or otherwise special/enhanced group on g.d.o.
+1 for yoroys wireframe (perhaps adding some of the extra activity tabs towards the bottom)
I also don't fully understand why these wouldn't represent/duplicate the community initiatives and/or become a set of places for sub-system maintainers.
--Ryan
Ryan Cross
Drupal Development Services
ProjectPier project management and collaboration software
Meta tools
These things, whatever we call them, are definitely going to be meta tools. But, they're not specifically meta groups in the g.d.o sense (i.e. they won't just be used to collect groups of groups). They're also sort of like "meta" issue tags (although they're not really a way to tag tags). They're also sort of like meta "book pages" in the d.o sense (a place to document a collection of documentation). Point is, they're a new tool. As such, they'll certainly be used by subsystem maintainers, D8 core initiative maintainers, other community initiatives, and more. But, they're not necessarily the "home page" for every community initiative, nor subsystem-maintainer, etc. All these people will have other tools. We'll still use issues to get things done. We'll still need documentation pages. These topic/team/whatever pages are just a new tool we'll have on *.d.o, and I'm sure we'll find lots of ways to use them. There might still be good reasons to have our documentation/book pages for community initiatives, maybe not. Maybe over time (or quickly) we'll decide these new pages provide a super-set of the functionality of those documentation pages and we'll replace those with these. But, that's not a problem if it happens -- even if it does, we'll still need the "documentation page" tool. It just means we'll have a more appropriate tool for organizing community initiatives than our current tool, and building (and getting people to use) more effective tools is basically the whole point of the Prairie Initiative.
Updated wireframe/description
hey all,
thanks for all the great feedback so far. You're right, putting the 'team' thing so heavily into the interface was not a great idea.
I've done a new wireframe and added it to the wiki post - come take a look and let me know what you think of this one.
(significantly inspired by Yoroy's wireframe - thanks yoroy :))
I've also added a new topic to the list - 'newcomers'
you might have a better name for that one too, but basically it's for people who are identifying as new to contributing to Drupal (in any way). thoughts?
leisa reichelt - disambiguity.com
@leisa
"I've done a new wireframe
"I've done a new wireframe and added it to the wiki post - come take a look and let me know what you think of this one."
Volunteering
I have been struggling with my initiative (Configuration Management) to figure out how to organize action and rally people. We do have a group on gdo we are posting on, but it has all the predictable weaknesses people have already discussed. However in addition to being a core initiative, configuration management is also a subject area that has been active for quite a while, and adding this as a topic page might be a good way to work a more technical topic in. This may be a little more narrow than you were imagining, but I think it could serve as a good sample for a type of technical interest, and I think it's important and would also potentially be helpful for me. We do have a gdo group now, but it has all the problems you can guess and it would be really nice to be able to organize things into a more helpful page like the wireframes here show. Like dww said, this is a new tool and I'll have other tools but I can see this one filling a need.
I don't have a ton of time to volunteer, but I do have some if I can tie it into this work.
...
This looks great and I would love to have something like this right now! Building of what heyrocker says above and I think it would be good to have a topics page for each core initiative. Awesome work thus far, the mockup looks excellent.
Questions:
What do each of the Edit links actually do - I assume one changes the title, one for the description (does this really need to be separate from the title?) I assume the Related teams edit allows you to manually select related topics?
The latest activity is a sort of teaser list - often this is not that useful because it only shows 5 or 7 teasers etc, however the overall activity of the topic is likely to be many times this so we end up with an extra click to see the "topic tracker", why not put the topic tracker on this first page with like 25 row table?
Whats the difference between clicking one of the links "Where we're at" links and using the "Show All" thingee? What happens when I click one of those links?
Maybe to far ahead here but in UX vein, how would I get something to show up here? Is the plan to use Solr? I ask because it will drive how we actually think and act with regards to titles and tags etc for our issues, group posts and so on.
Long tail in addition to short tail
It seems from other's comments that they're envisioning that topic pages will be created manually. Which is confusing me a bit as I'd assumed that topic pages would replace the existing tag pages -- e.g. the search page you see now when you click on a tag. Or in other words, this effort could be titled "Making tags a lot more useful".
Making topic pages different than tags doesn't make sense to me. We'd basically then just be adding another way to tag items which is redundant and confusing.
The way I'm envisioning is that when this is coded up and rolled out, each tag page automatically becomes a topic page. So immediately there'd be 1000s of these topic pages. If you wanted to add an issue to a topic page, you'd add a tag just as now.
And once we have the topic pages, then people would go to the topic pages they're interested in and start following them as well as add the additional contextual information such as associated documentation, groups, maintainers, etc.
I worry if tagging is different than adding something to a topic that topic pages will be underused. Associating something with a topic should be a simple cost-less operation that anyone can do. If you have to manually create topic pages and if adding an issue to a topic page is a new operation than it'll be perceived as a "special" activity that only "insiders" can do, somewhat akin to what changing an issue status is now.
I think topic pages should be broadly used in all sorts of strange and wonderful ways that none of us anticipate. So in other words, topic pages should have a long tail in addition to a short head.
Kyle Mathews
I think the way I see it is
I think the way I see it is that topics sit on top of many tags, thus a tag is one degree (in this or that direction) more granular and should be more specific and to the point, without the distraction of the full topics page.
Right now we use the tagging system to generate a topics-like page beacuse we have nothing else, no other way to track broad issues such as UX or accessibility because they're not module or system specific - so we use tags, in this case topics would replace tags and perhaps even allow us to abandon these generic tags (solr or another system would need to be smart enough to aggregate the right content to the topics page).
I would be thinking about the performance implications of having a full topics page for each tag - I did something like this for a big news site and we ended up having to abandon it - the cost of generating these rather heavy pages for every tag was too high.
One problem with this is that
One problem with this is that a lot of these sections don't apply to a vast swath of the tags in use, many of which exist only for organizational purposes. For instance, are we going to have a topic page for 'needs backport'? While I conceptually adore the hidden and weird discoveries that would come out of it, I also feel like those pages would be something else from what is being discussed here (what I don't know.)
Take advantage of existing tag clusters?
It's beyond my expertise to speak to implementation of this idea, but here's what "needs backport" (just as an example) connects to:
needs backport (6 issues)
Advanced Use Cases (1)
HS4 (1)
views (1)
needs backport to D7 (3)
Performance (1)
API change (1)6:00:37 PM
Of course there are 5 other backport tags that don't typically connect with the top-level "needs backport", but I suppose that's another issue, possibly related to the reduce duplication efforts.
Jeff nails it: I think the
Jeff nails it:
This is the initial list we came up with, it's up there in the wiki but let me repeat it because I'd like to convince you all on the great value of having a short high-level topic list:
Development
Design & UX
Documentation
Translation
Marketing
Learning Drupal
Accessibility
Security
Support
Performance
… and then maybe also
Newcomers
Community Guides
E-commerce?
Drupal.org (webmasters on d.o, g.d.o, infrastructure team) ?
Git?
The idea is to come up with as short as possible list of highest-level topics that let you choose a path to explore.
Obviously 'Development' is really too general and would probably be best served with sub-topic pages that each can easily be as rich or richer in content as other top-level topic pages. That's ok.
We don't want to deny the fact that you could probably make hundreds of these given the size and diversity of our community.
It's just so much easier for people to make an initial choice out of 10 options instead of 1000 (Paradox of choice). And that's the main objective of these pages: for new members and potential contributors to quickly zoom in on a topic of interest and go exploring. For example, look at the left sidebar on yahoo.com (which is a pretty big site, yes?) and even there the initial choice there is picking one topic out of roughly twenty options.
So I would like some feedback on the initial list. Are we missing topics of comparable weight and importance for this level?
Imagine you just signed up on drupal.org and this little list would be checkboxes or links on your profile page. Any obvious big ones missing then or does this list capture enough of the Drupal universe to go exploring?
Heyrocker: the configuration management initiative would be a pretty good test case. Within the development topic it is quite the heavy-weight subtopic.
...
I think you are missing Theming - it draws on the disciplines of both design and development but in Drupal its simply way more developer orientated but does not belong in the same space as say the Web services or Database stuff (its not hard core development). I can see how they could be combined, but really they are quite different disciplines - for example re-writing some core theme function is probably not going to interest UX at all, and we're going to be doing lots of this in D8 (fingers crossed).
hrm... theming...
yeah, theming is conspicuously absent, isn't it... mostly so that we can have this conversation :)
the first draft of the topics originally had Usability, Design and Theming etc. which is pretty standard Drupal taxonomy (in the proper information architecture sense of the word), but, as I think I mentioned earlier, I'm kind of keen to bring Design and Usability / User Experience together, because IMHO User Experience doesn't exist without design and these two groups SHOULD spend more time in each others presence, even if they are at times talking about things that one part of the group isn't particularly interested in.
this does beg the question as to where theming goes... because it seems weird to separate it from design, as you've said.
so, options as I see it are:
1. stick to what Drupal currently does, with Usability/User Experience in it's own little bubble and Design/Theming paired
2. put design and usability/user experience together and then have a separate 'theming' topic (where we focus on implementing design into code/Drupal rather than the practice of design)
3. put design in two places: design and ux, design and theming, each with their particular emphasis.
perhaps there are other options?
none of these are perfect solutions....
thoughts?
leisa reichelt - disambiguity.com
@leisa
I think you've framed the
I think you've framed the issue well and the options are logical.
2 is the most logical - in Drupal development themers tend to implement designs rather than do design. We (themers) are the bastard children of Drupals front end development demands and know a lot about code and care more about how to implement something than what it is we're implementing. We have a very broad range of topics and experience levels - so anyone coming into that topic is likely to find something that might interest them (from minor CSS issues to major PHP development discussions). Splitting off design/UX makes sense - if you're more interested in design then you have a topic to explore, but not be bombarded with code development issues which is what you will get if we pair design with theming.
Counter question
Where would you expect theming to live under? The 'theming' label is such a drupalism that I wonder how much information value it has for newcomers. I would expect theming related tags/subtopics to show up under multiple topics. Because yes, theming is indeed quite a grey area between design and development. Heh, from that point of view you could put theming as the parent of allmost all the other topics :-) Which would be missing the point, so I'm on the fence on this one.
...
I don't think theming is particularly gray, but rather "broad". A Drupal themer knows CSS, HTML, JavaScript and PHP. In Drupal all these things interact with dependencies (so to speak), e.g. theme functions (PHP) generate markup, we can use a function to add CSS for whatever reason (drupal_add_css()), drupal_add_js() can inject settings as JS hooks. How all these things work together are what themers care about, do designers care about this stuff?
I think beyond Drupal "theming" could be seen as kind of gray, but once you get into drupal development (especially core) you quickly realize that its not gray at all and its all about writing patches with the intention of making the task of implementing design better.
fair enough
Ok, that makes a lot of sense. I guess my main concern isn't so much tags vs. topics but that we make it really really easy to create new topic pages and to add issues and other content to the topics. Actually, more then easy, make it so it almost insists/begs you to place everything under the right topics like Quora does so nicely.
So stuff like suggesting topics, the ability to add/remove topics inline, no restrictions on who can modify topics, adding new topic pages inline, etc. are critical.
Kyle Mathews
shortest possible list / easy to create topics
so, as I see it, we've got a bit of a conflict here...
I can totally understand why you want to make it dead easy for Topics to be created (and as you probably know, a lot of the concept work behind this is modeled on Quora). But on the other hand, if there's no friction around creating topics then we're not going to have a short list for very long, are we?
personally, I think that groups not gathering enough of a critical mass is more of a risk for their success than not being about to create a topic when the idea strikes you... but I wonder whether we can start with a small list, have a 'manual' mechanism for creating new topics, and then after we watch what's happening for a while and hearing what people are saying, see if there is a big demand to make lots of topics or if we just need to add a few more that we missed that ppl really want.
means that we should probably include a call to action asking for feedback on the topic pages in the template to begin with.
leisa reichelt - disambiguity.com
@leisa
too many topics not a concern imo
I just went over to Quora to double-check how they do things. There when you click to edit the topics at the top you can do a few things. You can delete already applied topics, add existing topics, or create a new topic and add that (which is one step).
Topics on Quora can be ordered into a hierarchical ontology/taxonomy structure. For example this is the ontology for the "life" topic - http://www.quora.com/Life/ontology (it's rather big) -- and this is essentially what we're planning on doing here. Create some top level categories and then various sub-topics. Though interestingly, any topic can have multiple parents -- not sure what that sort of structure is called. See the drupal organize page for example - http://www.quora.com/Drupal/organize. Drupal has 2 parents and 9 children.
When you create a new topic on Quora however, it doesn't get placed into the ontology right away. It exists in a kind of unconnected undiscoverable space until you go in and manually add parents to it.
So how I'd see it, the top-level list of categories is setup manually by drupal.org administrators and can't be changed. So that would solve the problem of keeping that list short. But then people could create any other topic they want and either place it as a subtopic to one of the top-level categories (or as a sub-topic to a sub-topic to a sub-topic) or if it's a one-off special-purpose topic, then it doesn't have to fit into the taxonomy and it can stay unconnected and probably unused except for the few people who actually care about it.
That might seem like a recipe for disaster but that's exactly what Quora does and if we remember the lesson of the wiki -- e.g. make it easier to fix mistakes/vandalism then create mistakes/vandalism -- so we make it easy to merge duplicate topics, remove erroneous parents, etc. then it'll be quite easy for a handful of "topic gardeners" to keep things relatively clean.
Also the multiple parent concept (if we adopt that) would solve the problem of what to do with the "theming" topic -- it could just go under both development and design.
Also -- I don't entirely understand your assumption that "not gathering enough of a critical mass is more of a risk". Why does it matter if a particular topic does or doesn't have critical mass? Also what does critical mass mean in this context? A topic page just aggregates, nothing would happen there right that would need a critical mass of people? To borrow from an old joke, if a topic on drupal.org doesn't have any followers, does anyone care? The marginal cost to adding an additional topic is zero essentially. As long as the top few levels of the topic taxonomy are clean the lower levels (and the unconnected space) can be full of all sorts of stuff that almost nobody cares about and nobody would ever notice.
Kyle Mathews
Thoughts on "critical mass" and multiple parent topics
I agree with everything you're saying about "too many topics is not a concern" so I won't repeat any of that.
Re: "critical mass" -- I think that's a holdover of thinking of these as "teams". If this was about teams, then yeah, "teams" of 1-2 people aren't really helpful. But, if only 1-2 people care about a given topic, it's not (necessarily) a problem. That's how I see it, at least.
<geek class="extreme">Re: multiple parents: That's what's known affectionately to us computer science geeks as a "DAG", a Directed Acyclic Graph (assuming we don't want to allow cycles where a topic is its own ancestor). This is how Git represents each repository, since a merge commit is just a single commit with multiple parent commits. A "tree" in CS-speak (something more folks are familiar with, e.g. a directory tree, etc) is just a special case of a DAG, where everything only has 1 parent. Once again, I'll encourage folks to read my previous thoughts on topic pages where I get into some of these details.</geek>;)Critical mass
so, as long as we do have the pre-set, limited 'parent' topics then I'm totally happy with following the Quora model and letting the ecosystem evolve - I too would be fascinated to see what the community does with this new set of tools. Also +1 to a non-hierarchical/multiple parent approach.
The critical masse rationale is this: I would love the topic pages to make it easier to communicate with segments of the community en masse. To allow a big shout out to the accessibility crowd, or the performance crowd or the configuration crowd or whatever, to start doing that thing where we let them know we need their attention. Even the ones we don't personally know. Actually, especially those ones.
This is a first step towards addressing the notification challenge (letting me know when there's something going on that I might be interested in contributing to) and also to helping newcomers easily find a tribe to associate with, an entry point into the community and opportunities to contribute. Having a short set of well populated topics that give a good spread of our key activities and initiatives can help accomplish this goal.
Geez. It feels like we're increasingly in agreement here.
Might be time to get someone to do a shiny PSD of this (give it a bit of visual polish) and to let you guys debate the best way to build it.
Oh, and to answer a few of the detailed 'what happens if you do that' as well.
leisa reichelt - disambiguity.com
@leisa
how will this work
Non-hierarchical/multiple parent approach is interesting but I am wondering how will this work in relation to activity aggregation and notifications.
Will parent topics aggregate and display all activity of their child topics? Will followers of the parent page get notifications from all the child topics?
If yes, then it might bring huge duplication, same issues/posts shown on multiple topic pages, spam of same notifications.
If no - then only purpose of this parent-child system is to structure topics and let people find the ones they are interested in? and apart from that there is no connection between parent and child?
no upward aggregation
I agree that having parent topics aggregate child activity would be completely unusable.
So yeah, in my mind, the only reason for establishing the relationships is to help people find topics they're interested in.
Kyle Mathews
It's great to see we have
It's great to see we have come to a agreement on what this should all mean, I am wondering where I need to look for the final wireframes? There are some differences in contents between leisa's and yoroy's? It'd be great if we can hash out the final details on those more specific parts, before we move to the visual design work (I can probably help with that, if needed).
most recent in the wiki post
the most recent version of the wireframe is in the wiki post at the head of this discussion.
would be happy to get your thoughts on it if you have some time - or if you can encourage some others who might be interested to come and take a look that would also be helpful.
leisa reichelt - disambiguity.com
@leisa
Working through the detail
OK. So in an attempt to nail down the details so that we can actually get to work making this, some thoughts:
I'll get wireframing the missing bits and also do an empty state version. Can I get everyone's feedback on all the rest of this now?
Also, can we start talking about the who/how/when/etc. of getting this built?
leisa reichelt - disambiguity.com
@leisa
Agree on nice URLs. Though
Agree on nice URLs. Though probably only for the top level topics.
Messages - Definitely would love the ability to send messages and ping people. Though mechanism needs some thought. For instance I see some restrictions as: only followers of the topic can ping others, pinging everyone who is following the topic is available once each N hours or N pings per day or something like that - to avoid mail spam.
As for "Most active" vs "Topic maintainers". I definitely support "Most active". Not every topic has so to say "official" maintainers, who, how and when will "appoint" them. Topic maintainers approach seems a bit more bureaucratic against more flexible "most active" approach, showing (supposedly) different people at different times, who are actively working on topic.
Comments
Note that I am coming at this from the angle of project managing a formal community initiative, and the needs behind that. I realize this is somewhat a diversion from the original concept of topic pages, but I also think there are enough similarities that it is worthwhile to try and make it work. Doing this on g.d.o right now is very painful and I would love to help anything that can serve as an improvement. I definitely do not want to start a feature bikeshed, and getting something up reasonably quickly is way better than anyof the items in this wish list.
1) Yes, definitely need real URLs, and ideally they should be as short as possible. Right now the group we're organizing configuration management around is
http://groups.drupal.org/build-systems-change-management
Which is really hard to vocally tell people when they ask you at conferences and the like.
2) We may want to make this configurable per topic if possible, depending on the type of page. For instance a general 'topic' page may be appropriate to have wide-ranging edit rights, but a more focused 'initative' page (in the context of dries-sponsored-initiative) may want to be more locked down.
3) For me, having a commit log would be nice, but its not necessary I don't think. We will need to figure out a way to configure the topic pages to aggregate from specific tags or projects. I'm not really sure how that would work. I think these should certainly all be available, but if you don't configure one it doesn't show up. We might want to aggregate or link to other offsite things as well (Twitter lists for instance.)
4) Yeah I already touched on this some, and it is to my mind the biggest technical hurdle, and its going to take some careful thought and architecture.
5) I agree that it makes sense to be flexible here, as initiatives can be all sorts of things.
6) I'm not completely sold on having one item of latest activity, however something that was more of an 'Activity Stream' would be really really hot. 'heyrocker commented on posting x', 'skwashd submitted a new patch to issue y', etc. Especially if you could feed it out on RSS.
7) I also like the idea of messaging, but we need to be careful with it and make sure it is opt-in IMO. If the topics are focused enough and the content applicable enough I don't think that will be a problem.
I would love to get involved in the how/who/when discussions of this. I can help and I'll have some time as part of the initiative. I desperately need some organizational help and I'm interested in figuring out how to get involved with d.o improvements anyways. However I don't know any of that now and I look to dww for guidance.
/about/
I like the URL's, but wonder if they should be:
www.drupal.org/about/development, www.drupal.org/about/designandux, www.drupal.org/about/translations
for consistency? It's the standard that I was told when we set up www.drupal.org/about/accessibility
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
To respond to the detailed
To respond to the detailed questions :
1) We should definitely find catchy URL's for this, especially in communication to others in and outside of our community. I do wonder what our strategy is within d.o IA to make sure that these pages are found and promoted. One of the major problems of the current community initiatives pages ( http://drupal.org/community-initiatives ) is that simply few people knew of their existence even with all the promotion that was done during D7. I think the "where will this all live" question is a fundamental one, still to be resolved?
2) We can move this ability to only people with documentation rights and up, however I am not sure that we need the restriction. People in the Drupal community are generally pretty hesitant to change the title of a page, especially for something that is used by a larger group.
3, 4) I think you have captured all activity. Documentation might be somewhat of a problem due to it not having tags or anything like that you can track, so you would need to track updates of certain books. I do believe all of those things should be there, but we should be very careful with their visual representation - it’s likely some mediums like issues queues will have more activity. I will reserve my comments for that topic.
5) It's definitely so, that we want any initiatives to be posted up. It's likely certain topics will have more specific initiatives (for example, the UX pattern library).
6) The activity stream seems very much like a twitter feed, which I believe is very helpful. What I am most concerned about that rather specific mediums like the issue queue take over this stream leaving little room for the other ones to take attention. Other than that I am excited how we will make this happen in visual detail, as there is a lot of different content that can be part of this stream (which is definitely a resource consideration down the line).
7) I am definitely in for the idea of messages, which would be e-mails? I do wonder how much it will be used, because we have this functionality on g.d.o and it its hardly ever used and I am not sure what causes that.
8) I do wish rather than a set bunch of links (Overview, FAQ), like you have in the top wireframe. We can choose ourselves which links we put up, often there are a bunch of important links one wants to share that is specific to this topic.
9) We can easily count activity, we did that in earlier data visualisations. I am a tad bit worried that it will give a skewed view though, because of our nature there is a small bunch of contributors who are very active in many topics who will always end on top because of the discussions they have over for example implementation(in issue queues). If you are meaning to use this as a "go-to this active person for this topic" kind of place it might not be very good. Yoroy's idea of having topic maintainers or key-persons up there, will be much better for this.
10) Could be on one edit page, with the different parts of the page? There are only a few area's which are static and human editable.
11) I do wonder, if we really need a parent child kind of relationship and not simply a relationship. When you are making the UI for this consider the depth of these child’s, which will have an impact on the usability of finding the parent or related terms.
@dww You might be the best one to answer the who/how/when question. It clearly doesn't fall into scope of any of the running initiatives around d.o, but is there a possibility similar to the git transition that this can DA run project?
A few notes
On 9, I think we should also include statistics about the top committers. And perhaps top "documentation editors". These are important metrics, especially for initiative pages, to show how things are progressing. I'm a bit more optimistic about our ability to find a good way of determining who's the "go-to active person" but definitely agree with having optional topic maintainers.
On tracking documentation - my assumption is that it'd have the same ajax/inline topic management tool for assigning pages to different topics.
On 6, preventing issue queues from becoming too noisy. I really like Google Buzz's pattern here of grouping together similar activity items. E.g. if there are 5 new comments on a single issue, those could be grouped together but still openable by clicking a toggle link.
8 - agreed. One example, a topic might want to link to articles w/ background info off d.o.
Kyle Mathews
clustering
I don't use Buzz, but clustering would be a valuable element in such a dense display or stream. I hadn't seen it mentioned in this conversation, unless I just missed it.
As far as 6, I think it will
As far as 6, I think it will depend on the topic and the phase its in. For instance, right now, in my intiative, all I have is postings, documentation and comments. I haven't made a single issue yet. As things get solidified, then yeah there will be a lot of issues and patches, then it will swing back. I think it is a natural cycle, and a glance at the activity stream could provide a lot of information about where a particular topic is at in any given moment. This will also be influenced by the topic itself. A documentation topic may have all sorts of differing activity than issues (although obviously those too.)
from a newcomer's
from a newcomer's perspective, i can tell you that the main thing that can be intimidating and confusing about the current site is the extreme multiplicity of topics; holding a bunch of that back on initial acquaintance would enhance the user experience both for new people and for people looking to explore an area they hadn't been in before in a systematic way; maybe you could just have a layer of sub-topics under the top-level topics -- people who go to a place all the time are just going to go directly there anyway
Getting Things done
There are great ideas and plans.
Maybe we should start implementing to get it real, show it to people and being able to iterate on it?
Just today discovered a comprehensive Document by Neill Drumm on that:
http://drupal.org/node/1006562
It wasn't clear to me that anyone can get a copy of the d.o. database, set up a local copy and happily start hacking away at it.
I think there are enough development sites up - would be definitely worth it setting up one for Prairie initiative.
So I am here for helping with the CSS and module wrangling. There is a lot we can do even without custom coding...
-- edit --
Applied for a Dev Environment: http://drupal.org/node/1166092
Life is a journey, not a destination
Machine is here
We got a brandnew machine now at http://prairie-drupal.redesign.devdrupal.org/
Editing files on there is by ssh and Key Authenticication.
Everybody that has worked on another dev environment of d.o. has access.
All others have to ask Drumm by creating an issue.
To best organize on this, I propose everybody whon wants to participate creates a local copy of the environment.
As nothing is changed on there right now, you might just as well clone d.o. as described here: http://drupal.org/node/1018070
This uses bzr, which should be very similar to using git.
We can synchronize the local copies by pushing stuff up on the dev environment that is good, and pulling the database and files from there.
You can also just contact me, so I can push stuff up there for everyone to see.
Life is a journey, not a destination
...
Are there any updates on the redesign efforts - or a queue of open issues? Cheers.
@Jeff well basically this
@Jeff well basically this would be about gathering a few people and create some proofs of concept. Would not need that many. I dug my head into the bazaar checkout and development site stuff so there can be some kind of workflow.
If you know someone eager to help out guide him/her over here. I hear Leisa has been refining the mockups with a designer to have workable mockups to use as a starting point.
Life is a journey, not a destination
The topics list
I think it's important to keep this list as short as possible. I'd say that we should aim at 15 topics if we can, and try to find the 15 most important topics for newcomers. Not people new to developing, but new to drupal.
Narrowing topics: I know this is importent part of drupal for many, but I would think that Accessibility is a part of Design & UX. If we want to promote that specific part of Drupal, couldn't we do it in another way than giving it a topic?
Thor Andre Gretland | Frontkom | Twitter: @thorandreg
Agreed we want to keep the
Agreed we want to keep the initial list as short as possible. Looking back at what we have, the list isn't that much longer than 15?
thorandre: accessibility should probably remain its own topic. It's not just part of ux design, accessible interfaces are defined at the code level mostly.
But lets just keep in mind that no shortlist will be able to cover everything and the exact list shouldn't hold up progress on this.
This looks like we might find
This looks like we might find some common ground. That is a great list.
"Community/Support/Getting involved" redesign little project is outlined at: http://groups.drupal.org/node/174999
The issue re: "getting involved" topics is on d.o : http://drupal.org/node/1010262
Well, that's a good list!
Well, that's a good list! Thought the list on top was the current list...
In my (unaware) mind the Accessibility part feels like Design & UX in every way regardless of where it's defined, but if you guys think it really needs a seperate topic -go for it! :)
Thor Andre Gretland | Frontkom | Twitter: @thorandreg
Finally getting a chance to
Finally getting a chance to read this epic thread.
1) Who is the main point of contact on this effort?
2) What is the status of this? Are any of the specific items discussed here already issues?
I notice that there's some ground being covered again and again, from checking old issues in other areas (old threads/issues even pre-redesign). It looks like we need a closing summary and a few decisions made. Otherwise this will be the thread that never ends. I'm comfortable with making a 60% good decision and starting ASAP.
I don't want to attempt to do a summary and step on someone's toes. Anyone interested in grabbing this?
Yay! Short version: design is
Yay! Short version: design is at least 60% done and at a point where we can start working on implementing. Which is where this stalled. More later when not typing from the phone. Talk to tvn in irc as well.
I imagine the d.o. 'get involved' start page would link to these topic pages.
Summary
I couldn’t find a newer version than this:
Here’s a summary of the main questions and possible answers with some links to actual issues thrown in. I’m checking with Leisa for a more recent mockup which I think was in the works. Main discussion points are 3, 4, 6 and 11
1. Yes we need nice URLs for topic pages.
Something along the lines of drupal.org/topics/topicname. We’ll be quite far in implementing topic pages before we can open the issue requesting these :)
2. Remove the ability to edit the name of the topic but keep the ability to edit the description.
Might make this configurable and role-dependent. Default to fixed title, editable description.
3. Other activity in the site that we can/should aggregate? We have Issues, Groups, Docs (handbooks) and Discussions (forums).
Others: commit log (Git), email-lists, related modules and install profiles, API docs, Events, sprints? d.o. front-page news? Drupal Planet RSS?
Should all of these things be there?
Nah :) I think Docs, Issues, Forums and Groups are primary and useful for any kind of topic. All the others are more specialized channels. I imagine a ‘Getting started or support-like topic might see more activity in forums and handbooks. Core initiatives want to carry over the thinking done on g.d.o. into issues on d.o.
4. We need to work out how you’ll actually label each of the above as being relevant to a topic.
This needs its own discussion for the big picture as it poses the biggest technical challenge. A possibly related feature request is Enable apachsolr ‘related posts’ block for issues (and forums?)
5. Initiatives - this is another editable field that anyone who is following can add to.
Possibly Initiatives are “simply” sub-topics? They certainly generate exactly the diverse activity we want to aggregate on this kind of page. See #11.
6. Activity - will show a ‘snippet’ from each of the ‘areas we’re active in’ as per above, as well as notification of new followers
The content mix will vary per topic and the phase they might be in, moving from groups and docs first to issues. A more unified design with less emphasis on the different types of content than the mockup suggests might be all it takes to make this work.
7. Messages? I still quite like the idea of being able to get a message out to all the people who follow a topic.
I would label this a nice-to-have, not a should-have. Who can send these messages? I think only in the more controlled, focussed topic pages it will be seen as constructive. The more high-level the topic, the sooner it will be seen as spammy?
8. Design for if you click on followers, share/invite, overview, FAQ links…
Aha! Tangible progress here:
9. Calculating ‘activity’ (as in most active in a topic), to begin with we can keep this relatively simple and just base it on number of posts (including comments) on issues/groups/documents/discussions tagged with this topic in the past, say, 3 months?
Not a critical feature imo. User pics in the activity stream should give you a good first impression on who’s active now. Maybe make the main acitivty list relatively long by default, say 25 or even 50 items?
Still, thinking about initiatives, it definatly would be nice to have at least the initiative lead be shown.
10. Important links need to be human editable as well. Need to wireframe a UI for this and adding related teams.
Lets go for a single list of hand-picked urls for this and look at how we can do this as efficiently as possible withing the given tools on d.o. As in: lets not spend too much time designing this from scratch, rather improve what we might have. What with the MVP and all.
11. Given the recent discussion re: ‘top level’ topics and ‘dynamic’ topics we probably do need to include the manage sub-topics UI from the start.
Main follow-up discussions we need to have:
latest
I've added latest mockups :
http://groups.drupal.org/files/topic_pagev10a.png
http://groups.drupal.org/files/topic_pagev10b.png
http://groups.drupal.org/files/followers.png
I'll add comments later as am in a hurry right now.
A quick chat with webchick
A quick chat with webchick resulted in the suggestion to wireframe the data entry form for a page like this. It would uncover all kinds of fun implementation details like:
latest mockups
Latest mockups are these:
- is a state for not-follower
- is a state for topic follower with possibility to edit certain parts of the page
Left side:
There is an idea to show history on the edit page, so you can't really edit anything without seeing the history (which might stop from making unnecessary edits). Though if it is one page, then link must be named something like "Edit/History". If it is just named Edit, it will not be obvious for people where to look for the history of edits specifically.
As an exact list of activity to show was taken next:
1. New issue / Issue update (comment)
2. New group / Group update (new post, new comment on post? - not too deep?)
3. New forum / Forum update (post)
4. New document page / Document page update (comment on document page and/or edit ? - not sure how we will capture this. I for one when work on new document page can make 10-15 edits during 1 hour, it will be major spam in the stream)
5. Topics:
- New topic follower
- New subtopic added (should we show difference between added existing and newly created topic?)
- New parent topic added
-Title of piece of content-
New/Updated -type of content- for -parent content-
In the case of documentation it is not clear what to take as parent, in many cases it is better to show the very top page of Documentation book than immediate parent for the updated content.
At the followers page "Sort by" supposed to have options like: Date of latest activity in the topic (ascending/descending), user name, when started following the topic.
Ride sidebar :
Roughly smth like this:
The basic idea is - having short list of "top level topics", which have no parents.
With links like drupal.org/usability etc. Only webmasters or some other users with special permissions can create these topics. Normal users can create subtopics of any depth to these "top level topics".
When creating new topic - you can choose any existing topic(s) as parent(s) and as subtopic(s). Topic can have no sub-topics but should have at least 1 parent. Only webmasters or users with special permissions can create topics without parent - in other words "top level topics".
They can be removed inline via remove icon near their name.
Here some permission restrictions should be implemented.
- when deleting parent topics - you can't delete last one. If topic has no parent - then it is converted to "top level topic". Only webmasters (or someone like that) should be able to do this.
To those interested in seeing
To those interested in seeing this implemented - here is a chance to push this idea into Drupal.org roadmap, vote: https://groups.drupal.org/node/312903!
For more information on the voting see https://association.drupal.org/node/18358
Pushing this forward
I posted some ideas and screenshot to https://www.drupal.org/node/1290740#comment-8910217
Feedback needed, please.
==================================
http://about.me/lisarex
Pushing this forward
I posted some ideas and screenshot to https://www.drupal.org/node/1290740#comment-8910217
Feedback needed, please.
==================================
http://about.me/lisarex