Implement initiative content type

Seems similiar to "milestone" feature of other project management tools / issue queues. For example, same basic concept as github's milestones. Might gentrify it a tad so that it could also be used that way. That way instead of tagging a bunch of issues needed for the next release (unstable or stable) we can just have a milestone and it's much easier to track as all the milestones for a project as they can be listed. In addition you get all the fancy stuff like percent complete which you don't with tagging.

In general looks great and looks like it will make a LOT easier to track what's going on since issues are at the heart which seems to be the best approach.

Yea, I could see initiatives having milestones inside of them, which might be better. Otherwise initiatives could be per-project or global shouldn't be too hard to code, but milestones within initiatives sounds really powerful and even allowing initiatives to span multiple projects (and sandboxes..oo) would seem to be a good idea.

Perhaps we should break off a new issue for creating milestones which I think can be done separately from this. Just needs to be designed so that milestones can have a project or an initiative as their parent.

EDIT: I end up create meta issues for essential milestones.

Can you clarify what initiatives are? Also, I think we should discuss the "Topic" pages, because those will be largely rendered useless by this - we should look into combining the two, rather than finding each others differences. Also why are we creating project management tools? Are they needed, for whom - and what meaning do they have?

Do note, I think this is an amazing idea and we need to have it. I actually already made a few wireframes before for an initiatives landing page, let me find those today and post them.

Generally +1 to the whole concept. Structured data++.

Re: milestones: #135800: Milestone management -- and yes, those seem like a separate beast than initiatives (which might have multiple milestones in them).

General thoughts

In some ways, these things are what most people think of as a "project". ;) Like, in the GTD sense -- a larger scale thing that has lots of subtasks associated with it. You can't "do" a project, but you can do tasks associated with it. And when all the tasks are done, a project is complete. But, obviously our existing project nodes are *not* the right tool for this job. So, this thing here is basically a tool to organize/represent GTD projects. At least that's how I see it.

That said, I'm concerned by the overlap between this concept, milestones, topics, meta issues, projects, and g.d.o groups. I think those all make sense to me as separate things (I think!), but I'm not sure the average d.o contributor is going to understand all the subtle distinctions. As a perfect example: "HTML5" is both an initiative and a topic. So, to be precise, I think we need to call the HTML5 initiative something like "HTML5 in core" since that's something that could be completed once enough tasks are done. Whereas "HTML5" as a topic won't ever be complete. I think that's a really important distinction that we need to get clear about from the very beginning as we're thinking about, discussing, and eventually naming these initiatives (assuming that's what we end up calling these things).

Actually, I take that back. I'm not clear how this concept of an initiative is different from a meta issue. They both seem like a way to organize a set of related tasks and figure out if they're all done yet or not. And yes, meta issues can definitely span multiple projects (#34496: [meta] Add Flag module to allow users to subscribe/unsubscribe without posting a comment is an active example of that). Is the idea to replace the concept + practice of meta issues with these things? If not, someone has to explain the difference. I guess the only difference is how you find them. Meta issues are in an issue queue somewhere (and therefore, associated with a single project), whereas these things live at some new navigation path. So, I guess that's an important distinction. But otherwise, these smell like basically the same animal.

Implementation details

A) I'm not yet sold that issue tags are exactly the right mechanism to associate tasks/issues with initiatives. For starters, since those are so easy for anyone to change, it's potentially easy for someone who doesn't know what they're doing to disorganize an initiative by monkeying with tags they don't understand. The flip side is that using issue tags makes it easier for lots of people to try to organize/curate the initiative, and that probably outweighs the risks. But, I wanted to raise it.

B) I'm not yet sold on views of issues. Lots of initiatives have roadmaps, and certain things that have to happen in certain orders. "Last updated" is a crappy way to view those. For some things, a huge pile of tasks that can all happen in parallel are okay, but for many, it's really an ordered list that we need to work down. Sure, the issues themselves could try to represent that via being "postponed" and ideally we could have pi_related to track issue relationships. But, I definitely think there's value in allowing initiative admins a way to give the issues in their initiative a specific order.

My concerns about both (A) and (B) would be solved if these things had a multi-valued noderef pointing to issues that you can reorder. I know that goes against your point, since you don't like how infrequently the existing wiki pages are updated. But maybe if we had a more structured tool that people had confidence it was helping them get things done, they'd be more motivated to update things when needed. The noderef would still allow us to do the %XX completed stuff, etc. Note: I'm not sold that this is better than what you're proposing, either. ;) I'm just raising it for discussion as an alternative implementation approach.

C) Should the initiative node type be an OG? Or is the "team" just a multi-valued userref field? Seems like a lot of the stuff you want to do in screenie #2 would be easier if these things were just OGs. Why point to a separate group? Why not just have the initiative *be* a group?

D) You seem to be implying that initiatives have some kind of categorization scheme (e.g. the "Drupal.org" part in your "Topic pages" example). Is that a taxonomy? Pre-defined set of options or free tagging? Is there a way to browse by category? Aren't those going to have a ton (100%?) of overlap with the project namespace? Assuming we standardized on one of the drupal.org-related projects (drupalorg, infrastructure, webmasters, whatever -- doesn't really matter) and core being the other obvious one, can anyone thing of a category of initiatives that doesn't correspond to an existing d.o project? I'm probably just being narrow-minded, but again, I wanted to raise it for discussion. B/c if it turns out that all of these things *are* somehow associated with a given project, that reopens the "how is this different from meta issues?" question I asked above.

E) It'd be nice to define what "most active" means. ;) Not a blocker, but if we're going to prominently feature that on the main landing page, we should all know what that means. Most issue comments? Commits? Some combo of the two? Some other metrics?

F) If these things are not OGs, how do the "announcements" work? Is that yet another new node type that has a noderef pointing to the initiative? Can people get those via e-mail or only RSS?

G) Can anyone create a new initiative page? Do we fear too much noise (e.g. if people start using these things to organize each release of their contrib projects)? Would that even be a bad thing? If the goal is to help people find stuff, are we just going to recreate the "holy crap, 8000 modules to choose from, now WTF do I do?!" problem?

H) When you search on the main landing page -- what are you actually searching? Just the title/description text of the initiative nodes themselves? Probably it'd be too messy to be searching issues associated with initiatives. But, that puts a premium on naming these and providing enough detail in the description that people can actually find them. However, in the mockup, the description seems like a 1 sentence teaser.

There's probably more I could come up with, but that's probably more than anyone's going to read already. ;)

Summary

In spite of my concerns, I think this would be really cool, and would be happy to help try to make it a reality (you know, in my copious free time). ;) I think this very directly aligns with the goals of the Prairie initiative so I'm tagging this accordingly. I'd love to hear what Leisa has to say about this, so I'll ping her about it, too.

Thanks for getting this started, webchick!

Cheers,
-Derek

B) [I see you wrote this later on] Seems like initiatives having a node reference with multiple values can then be sorted which would work great. Webchick and I did a fair amount of structural discussions around this...defnitely seems like it can be done quite cleanly.

G) I think that is a great point for discussion, definitely seems like initiatives should be restricted and milestones (which can work at a project level) can be treated more like issues.

In response to #9 and in general, just to go into a bit more detail of my thoughts.

All the data should be laid on top of existing issues and projects, all references/relations of some sort. I think the workflow that made some sense was the following.

Milestones within a project

1. Create milestone
2. Select and optionally order issues from project queue. (using either autofill or possibly a view with checkboxes)
3. Add meta data and save

Milestones within an initiative

1. Create initiative
2. Select issues to be apparent of initiative (similar to milestone as above [probably same mechanism])
3. Create milestone
4. Select and optionally order issues from initiative
5. Add meta data and save

That way initiative can contain milestones and issues separate from each other. So issues can be removed from a milestone (or in more then one) and not removed from the initiative, etc, etc. It also allows you to use any combinations of the pieces or none as all the data is modular and stacks nicely.

Since initiatives can reference projects then milestones from the projects could also be utilized, issues, etc. Something like that would be great for initiatives with sandbox projects that could self manage as well as the initiative managing at a high level. Can create as many milestones encompassing others and levels and makes sense...or as few/none.

My intended was to lay out the capabilities I think make sense and some basic structure. As for the specific tools like OG and such that probably needs a bit more discussion, but I am interested to see what people think.

Initiative
-> meta: ...
-> issues: nids (issue nodes) (sortable)
-> projects: nids (project nodes) (sortable)

Milestones
-> parent: nid (either project or initiative)
-> issues: nids (issue nodes) (sortable)
-> meta: title, description, tags, ect
-> weight

I think leaving project nodes and issues alone is probably best and having all the data simply sit on top.

Ok, its good to see how it fits with topic pages addressed. I think this addresses my concerns. I could definitely see the different UX initiatives using this.

Woohoo, exciting! Lots to digest here. Great to see acknowledged there is significant overlap *and* differences with Topic pages. For reference, the latest breakdown of desired functionality for Topic pages is here: http://groups.drupal.org/node/179394. We'll want to compare that with the rundown of specs we come up here.

Seems that Initiative pages are about enabling *existing contributors* to do more better faster where Topic pages are about making it easier for *new, potential contributors* to find a place to dive in. Both very important, would love to see focus on building the overlapping moving parts for these.

#1027608: Use forum to make Discussion tab/block for Book pages seems related as well.

Subscribed!

subscribe

Subscribe! This is awesome!

I'm overall in favor in principle. I'd love a better way to organize WSCCI than http://groups.drupal.org/wscci (which is 3 manual panel panels and one view that I had to guess at to figure out the one I wanted; SO not helpful...).

My main concern is the "% done" concept. I know PMs love having a list of all tasks up front so they can see burn rates and estimated dates of completion and so forth. That's their job, and in a commercial project I can totally see the use of that. In Drupal, though, I've never worked on a larger initiative where it was possible to make those sorts of estimates. The list of open tasks goes up and down all on its own, completely unplanned. Half of them are discussion tasks, not coding tasks, and half of those are "two steps forward, one step back" re-discussions. Even when they're useful and productive, it's not something that you can plan for. And that's assuming you could make a list of tasks up-front. That's not always feasible.

The way I'm running WSCCI is to not try to build out tickets too far in advance, because we don't necessary know exactly what those tickets will be. There are also a ton of dependencies, which of course we cannot adequately capture right now. So throwing that into a %done model, the %done on WSCCI would bounce between 5% and 90% depending on what day it is, whether we count discussion threads I didn't create that ended up marked "closed (by design)", etc. I believe CMI is the same way.

DBTNG was at 0% complete until the initial patch landed, at which point it went to about 90%. Then we kept rewriting stuff as we implemented it throughout core. If you went by the number of open issues in the DB queue, it's less done now than it was after Szeged. :-) Those are mostly newer and unexpected edge cases caused by one database or another being broken in some brain-dead way. So, when did we get to "done"?

A better way to organize "here's the hot topics we're focusing on right now, here's the stuff that's blocked on those, etc.", however, would be awesome.

Well, assuming an initiative can be managed in a sandbox and such lots of issues can be completed and committed before it ever lands in core. As for being able to estimate I would agree that it will probably not be that accurate, but I think see how much is done if handy enough without estimation.

Thanks webchick for the thoughtful responses to all my questions!

- Great to see it clarified that these are going to replace meta issues, too.

- Yes, I'm sure we can properly (re)name these as needed, I mostly meant for this issue so that we're clearly communicating what we mean as we hash these out.

- A, B) Yeah, that all makes sense. Draggable views could perhaps be very cool. I imagine #1093650: Provide VBO support for issue management would fit in very nicely here, too. Still might want the multi-valued noderef, though, and layer draggable VBO views on top of that. VBO could also be a great way when you're "in the flow" of your issue queue to associate issues with initiatives (and milestones) (and might help answer the concerns from comment #18). In fact, if we put some love into that, we could have a VBO view with the current nid as the argument for a block on issue nodes that let you do all the same kinds of activities (assign to/remove from X initiative/milestone, etc) to get you a lot of the way to "in-place" editing/management on individual issues.

- C) Re: OG: Yeah, definitely OG on d.o, not g.d.o. See drupal.org projects as Organic Groups for related discussion.

- D) If initiatives are tied to projects, is that a single node reference pointing to a project node as the parent of an initiative? What about initiatives that span multiple projects? Why/how do you pick which one is the "parent"? If milestones can have either initiatives or projects as parents, why can't initiatives? Can't we allow nested initiatives? Am I getting too insane? ;) Either way, I agree whatever we point to as the parent(s) should have a view of child initiatives (quite prominently displayed, in fact).

- E) Although we don't currently have a commit/issue mapping table, we absolutely should, and we're talking about that over at #443000: When viewing an issue, display a list of commits that reference that issue # (and #493074: Back-link to the commit as a comment on the related issue.).

- F) Okay, I guess an RSS feed URL is okay, although I prefer OG (for these, topics, and project nodes) and then just having an "announcement" node type. An optional pointer to an offsite feed is okay, too, but I'd rather keep everything in one place. It'd nice to be able to use the [#] filter in your announcements, for example.

- Agreed on G and H on these being open to anyone but findable via concise + accurate titles/descriptions, with useful, easy to see and grok metrics. Which of course is what we need to do with projects to try to solve that problem, too.

---

I agree with boombatower that these (and topics) should be a layer that sits on top of projects and issues (which ideally we don't have to alter at all to support any of this).

Also agree with yoroy that although these and topics are different, they can probably share a lot of the same plumbing, which is great.

+100 to Crell's main concern about %done - very well stated. However, I think it's still a useful thing to have the ability to automate (for initiatives that will have a pretty clearly defined set of issues from the beginning). So, perhaps we should give initiative owners a choice about how prominently that's displayed. Basically, a switch to flip for initiatives like the ones Crell is talking about (of which we'll have a lot) so that the %done concept is not IN YOUR FACE as the primary thing you see when you look at them.

I) Another really nice visual indicator we could have is a sparkline of comment/issue activity. Those should be first (if that's the primary way we want people to find these - see G) and the %done can optionally appear below the activity sparkline(s). Probably a commit activity sparkline as well (see E above), although for some initiatives Git commits won't mean anything (e.g. documentation restructuring). So maybe we just want a series of checkboxes for all these visuals and let initiative owners turn off the ones on their initiative pages (and therefore search results) that are inappropriate for their initiative. There'd be a subtle link to a "see all metrics" or something so you *could* find any of them on any initiative, but you wouldn't see them "above the fold" if the maintainers didn't want you to.

Although this is a bit premature, so far everything we're discussing would fit great within project_issue itself. I'd be happy for this to be implemented and deployed on d.o as a Feature(tm) included with project_issue. If that changes and we start veering into totally d.o-specific things, we can revisit this (and I certainly won't block progress if it goes that way). Let's be flexible about it. For now, I'm happy to say this would be maintainable under project_issue (and a very excellent edition to it). Maybe we can mark #569552: Provide a mechanism for issue meta discussions duplicate. ;) Lots of related prior discussion there for the interested reader (although a lot of it is obsolete given #1036132: Provide a mechanism for issue summaries)...

Posted: #1302588: 403 error on second "Community Initiatives" link sends a very disturbing message.

Sorry; Originally posted #1302588 here but moved it to a separate issue after it failed to incite a response. Should have come back here and restored the original status. My fault.

More on-topic, can we include in our dream-sheet an automated link-checker that removes (or at least hides) community-initiative page links which are broken or unauthorized for the anonymous viewer?

(chuckle!) Where would we all be without webchick to keep us on track? Found and subscribed to #921568.

I ran through a few more design iterations building on my notebook sketches with webchick today and we managed to come up with the following based on a hybrid between some of her concepts and mine. I love Mockingbird for collaboration, but unfortunately it's difficult to annotate, so I've added numbers to associated with annotations I'm going to list in this comment. They're listed roughly in order of prominence. Further, I've gone with the following general design principals:

• The left hand side of the page is full of things related to "all initiatives on d.o"
• The right hand side of the page is directly related to the initiative you're viewing
• All of the views-esque stuff on the page have links that allow people to see more info (generally the top 3 things are displayed). These are always located in the same place.

Also, there are a lot of cool potential things that could happen with a design like this. Things like allowing these pages to be configurable on a per-initiative basis, much like a dashboard. I recognize that these things take considerable engineering effort, and these designs err on the side of "engineering heavy", but provide a good concept to pick and choose from.

Here are the annotations:

1. Title and image - This is a user-defined title and image for the project (e.g. Whiskey could have a picture of a bottle of Jack Daniels... or just me on a Friday night)
2. Progress indicator - An initiative-owner defined completion percentage.
3. Media block - Quick links to contact, view Tweets, subscribe to updates, RSS, IRC channels, etc
4. General info - Just a place for a description.
5. Top contributors - Show who is a part of the team. Allow for self-assigning of titles or assignment by the initiative owner - much like we have with modules and themes within Project.
6. Top initiatives - this is where you can find popular initiatives on all of drupal.org, search for them, or create an initiative page. This mock up does not include a design for an overall drupal.org initiative page, but the idea is it would have similar content.
7. News - a view of the top few news posts for the initiative
8. Upcoming events - a view listing of the next few events. This was originally a calendar control, but calendars are often difficult to read at a glance. Now it is modeled after the events on http://oregonstate.edu/
9. Top contributors - a thumb gallery of the profile pictures of the top initiative contributors. I like the idea of having *something* like this on the page, but I'm not 100% stuck on this concept.
10. Get involved - a call to action linking to content pages on drupal.org about becoming a volunteer or contributing to the community. The placement of this might want to be altered, and a link-list is boring, but I couldn't think of anything better for now.
11. Recently finished - a view of the last few initiatives that were marked as closed or completed by the initiative owner. This could also be a manual list if we want to have more control on what shows up (e.g. so we don't get initiatives that just died and were closed), but that requires someone to maintain it.
12. Project planning - This is the most complex part of the page. Each vertical tab groups lists of issues together into those that are "open" and those that are "closed". The vertical tabs are user-defined and can be things like sprints, milestones, phases, whatever. This allows us to run multiple project types (i.e. agile, traditional, whatever else there is). The categorization issue, or, how to get issues to show up in each bucket, is an open question that webchick and I went round on a few times without really settling on. I know dww had some good opinions on how this should be managed. Further, it would be nice to be able to edit issue attributes, like assignments and status, from this screen.
13. Project activity graph - A graph that shows the frequency of the various activity types for the project. This helps people assess the project health.
14. Project velocity graph - Some way of measuring velocity toward completion. This is typically done with "points" in agile projects, but I'm not really sure what makes sense here. We still really could use some measure of how fast we're moving toward completion.
15. Issue breakdown - A pie chart of issues that are not started vs. completed vs. in-progress
16. Recent activity - a Yammer-style activity feed for the initiative. I hope to be able to make this slice-and-diceable via views of different update types (comments, people added to the project, new news items, commits, whatever). It would also be great to be able to subscribe by update type.

Open questions:

• How is membership in an initiative managed? The organic groups concept of "open" and "closed" may be the way we want to go here as some initiatives require a high level of control while others will take all comers.
• How do issues show up in the project planning tool? Our current system of tags has some pretty serious limitations (anyone can tag any issues with a tag), but I'm not really sure how to solve this. Maybe dww or webchick and chime in here as they're more aware of the technical capability within drupal.org than I am.
• How will we manage assignments? I feel like issues should only be able to be assigned to people within the initiative group (so random people don't go assigning issues to other people), but there are technical limitations here.
• What is our measure of "velocity"? Do we do a points system for issues? Do we just worry about number of issues? Do we change this to be an issue burn-down that has a floor and a launch date? I really need to think on this one.
• We need a comprehensive listing of the types of events that would be tracked in the activity feed and a model of how that activity looks within the feed.

subscribe, i hope to be able to work on some of this stuff with webchick at badcamp

Great work. Lets remove some stuff :)

### Too much stuff in the left sidebar:

6: yes, provide quick access to other initiatives
9: distracting in this context. This info lives on the initiatives overview (listing) page
10: We shouldn't need these so explicitly. The actual overview of 'agenda' (why, how info) and 'activity' (what, where info) should make you just itching to jump in. Postpone on these generic shout out links.
11: 'Recently finished initiatives' is also initiatives listing page material, not for the individual initiative dashboard. Also, optimistic :)

Basically, this could be condensed into a link back to initiative listing? Left sidebars are distracting anyway :)

### Content column and the ordering of components in it

4: Intro text to set basic context of contents for sure, but beware the wall-o-text. Allowing more that 2 or 3 tweets worth of bla here will hamper the purpose of this page. Link off to the 'about this initiative manifesto' real quick. Maybe the project plan lives there too, on this manifesto (as a seperate tab?)

I think the order of 7: news, 12: project planning and 16: recent activity is boring and is putting the static bits first. Instead focus real hard on exposing actual Activity first. Seeing faces and activity around *titles of issues and discussions actually happening now* is what will give good overview and provide actionable hooks for joining the effort. Expose activity first, provide context second. We'll have to see what the best mix will be: 3 items recent activity + large chuncks of supporting content or 10 (25?) items of recent activity and a lean and mean supporting right sidebar?

### Right sidebar, infographics oh my!

3. Get in touch links. Could we have a 'Follow' button here?
5. Top contributors. Yes, these are the people making things happen in here.
8. Definately maybe. Could it be part of the 'News' listing? But initiatives do have meetings, so makes sense as these are good opportunities to get introduced.
2, 13, 14 and 15 together is too much. We have to keep in mind that we're still cat herding here. I imagine that for core initiatives, is is the core dev cycle that provides a fitting inital frame for a timeline, with code thaw, feature, code, string, ui freezes, slush, exceptions and what not. Webchick started Tracking community health via metrics which seems relevant here. Focus on 'what to track' first.

### To your questions:
1. How is membership in an initiative managed?

Follow button? Keep it simple. How much membershipness is needed from the start?

2. How do issues show up in the project planning tool?

Yup, figuring out how to tag, reference, crosslink stuff is essential and likely the biggest technical challenge. I probably started #1290740: How to label, aggregate and expose issues, docs, forum posts and groups to Topic pages a bit too soon, but yeah.

* How will we manage assignments?

Let the people handle it? Since recently we can assign issues to others. Etiquette and practice should drive this, I don't see a need to pre-emptively work on managing tools for it.

* What is our measure of "velocity"?

See thoughts on the infographics above :)

* We need a comprehensive listing of the types of events that would be tracked in the activity feed and a model of how that activity looks within the feed.

Yup, topic page design has a good proposal to look at:

http://groups.drupal.org/node/144584#comment-592174. for the full pagemockup.

Tralaa, exciting! :)

Feedback for what's needed from a Drupal 8 initiative lead:

1. I don't need timed iterations, I need topic areas. While there is some dependency between things going on and some things need to be done before others, we can discuss overall concepts, user experience mockups, etc. while the underlying API work is going on, so my initiative tries to shoot in as many directions possible at once with the risk of overwhelming people but making more progress at the same time, instead of postponing things. So I'm looking for making sense of lots of things at once, vs. hiding things to show in future milestones/iterations.

2. I needed an overview of my topic areas now while all this is being discussed/developed, so I created a mind map and posted at http://drupal.org/node/1260534. You can see I can keep this inside the three level structure "imposed" by mindmaps, but for the structure to be cleaner, one more level would have been better (to have UX and API issues childs of a bigger item on the topic). I'd love to keep UX and API issues listed separate so that I can attract the right type of people. I understand having four levels of items would be harder to understand when diving in, even though it would be more true to the structure. Oh well. All-in-all the above topic page plans seem to allow for 3 levels (the main initiative page, topics under that and issues under that). I'd need to have weights for the issues in these lists, so I can move "current focus" issues on top. Current issue metadata has long-lasting properties, no way to mark current focus items. Some of my issues are important to get through at the moment, they are not major but blocking more work to be done and block moving forward.

Hope this helps a bit.

This is a fantastic proposal! Personally, I've been quite miserable with the project management aspects of running an initiative so far, and this seems like it would be a tremendous help in that respect.

Tags

I don't like tags for this. At all. I already get grief for tagging issues for sprints and when I tag CSS issues under the initiative. People complain about the inbox spam and the "abuse" of tags and managing multiple tags is a nightmare. I don't mind switching to a "PM mode" for this if needed because the gains are worth it. I actually stop myself from attempting to organizing issues the way I really want to because I don't want to spam inboxes and deal with the complaints and BS. It would be great to do this sorta behind the scenes.

Sprints/Milestones

Sprints have been largely unsuccessful for our initiative. We've had 9 of them so far, and never once made our target. The backlog is huge, and I'm currently re-evaluating the whole structure of how to do things in this respect. I'm not sure this is what you intend to use Milestones for, but I'd likely try to abuse it. While I'm generally concerned with the amount of time PM tasks take when managing the initiative in general (as opposed to the time I end up having for everything else), I realize the current situation is broken and would really appreciate the help that something like this would provide in the long run.

Topics vs. Timed iterations

Like Gábor, I don't need (or want) timed iterations either. One thing I would really like to see as part of this is a way to sub-categorize issues of the initiative. This would be helpful to track progress and to give those looking to contribute a better way to see how they can help. For the HTML5 initiative, it would be nice to be able to subcategorize by "Templates", "CSS", "JavaScript, "Theme functions" and "Other."

Percentage Complete Metric

In general, I don't really like the percent complete metric either. I think it's going to be misleading most of the time. With HTML5 for example, we've got well over 100 issues in the queue and there will be plenty more to come down the line. Even if there is a high percentage complete, it worries me that it may look like we don't need more help, when we really do.

Top Contributors

Another red flag here for me is the "Top contributors" thing. Most of the time the people mentioned in commit messages are the ones that have posted patches. What we are really lacking is people willing to review and test issues, and many times this is way more important for moving issues along than the patch itself. We need to give credit for that.

From what I've read here, it seems like comments will be used. It would be nice to take this a step further and allow the initiative owners (and hopefully a few others) to "flag" comments and give contributors "kudos" in issues to help make this more useful. Ideally, this could be a metric displayed in the issue, such as a "Top Contributors to this Issue" block with an automatically generated list of users that can be tweaked based on the initiative owners "kudos." Sort of like the way Dreditor gives you a nice starting point for a commit message, and then you can tweak it. I believe this could help motivate people to get involved and serve as a "who to talk to about this issue" for those looking to help moving it forward.

It looks like you're talking about both things:

1) Individual pages per initiative
2) The landing page for "community initiatives"

There was a previously posted issue where we summarised an earlier conversation w webhick. I am marking the other issue related to this as duplicate.

#1288378: Create community initiative pages

Also there is a related community initiative to divide out the Support/Community/Get Involved top level navigation and landing pages which will depend on much of the work on topic and initiative pages. We're tracking the related issues here http://drupal.org/node/1289748

Yoroy,

Thanks for the feedback!

Couple things:

In terms of the left sidebar I was trying to present it as "encapsulated design" - basically sectioning off a portion of the page where people can go other related places easily. It has sort of franken-mostered on me though, and it was my least favorite part of the wire. I *do* think there is a compelling reason for users to be able to find related initiatives, but that can just be a block that goes somewhere.

I agree on the initiative description being too long in the wire. This should be really short. However, in terms of the other ordering I'm not really sure what is best. "Activity" is an awesome way to show that something is happening, but news posts generally provide more value as they're richer content. The page serves the dual purpose of getting people excited and interested about the initiative and also working as a PM tool. Someone better at UX than me should make this determination, or we should make the order configurable (seems like overkill for now).

For 13,14, and 15 I took the common metrics I use as a PM. We could keep this more simple to start with, but they're relatively essential for my day job. I'd like to fight for keeping them around if we can figure out how to make it all work.

I also admit I stole some ideas from the topic page design for the activity feed. Nice work going on over there :-)

Gabor,

To #1:

The point of the "iterations" is that they can be anything you want them to be. It's just a high-level single tier categorization system for issues. If you want "Iteration 1" to say "Cookies" and "Iteration 2" to say "Milk", then that's totally possible. Consider those categories to be similar to meta-issues and the overall initiative page to be similar to a meta-meta issue (When did drupal.org is get so hipster?). You can define it however you want. I don't want to force people into an agile framework with iterations/sprints that space periods of time (even though I do believe that almost every project should be run this way). The idea here is that we allow people to run whatever style they want to - not push people in a direction.

To #2:

People start to get really confused / things become really difficult to follow when you create "onion projects". Typically, that's why there is a strong separation between solution architecture & functional specifications from things like user stories & requirements. Specs tend to be really detailed and personal - it's almost impossible to plan work for a team around a spec, but the spec provides the necessary detail to develop something properly and maintain a cohesive vision of a project scope. Typically, you want to keep things as "flat" as possible when actually trying to run a project team (hence why meta and meta-meta issues drive me kind of nuts). It creates a more simple framework for understanding where a project is at, what needs to be done, and planning for work / resourcing. That way, people don't get bogged down in details and are able to focus on more manageable pieces. That said, there *should* be a place for project documentation and detailed information like mind-maps and solution architecture style documents. That is missing and I think it would be valuable to include.

Jacine,

Angie mentioned you were having some issues with the sprints / project planning. I think we're going to try and arrange some time to talk and see what kind of help we can offer.

Thanks for your thoughts - I especially agree on tags. I really want to try and come up with a good solution here. We've done some initial brainstorming, but nothing we particularly love yet.

In terms of the % complete - this would be defined by the initiative owner. It's not going to be something auto-generated, because that isn't very representative of most projects. Other things that have been proposed were a sparkline showing activity, or a stoplight graphic indicating overall health. Regardless, we need to have some way of showing the at-a-glance status of the initiative.

Your thoughts on top contributors is interesting. I'm looking to show who the leaders of the initiative are - what if we made this something that the initiative lead chose manually? Kudos / Karma systems have traditionally been a bit of a quagmire, but maybe this is the time to tackle it.

Superb to see this idea taking shape!

First, Who is the target audience for this page? Because right now, it is leaning heavily towards the initiative leader/PM. What's missing is 'how to get involved' with this initiative! I thought one of the goals of revamping these pages was to make it easier for people to get involved. While we will make design changes to the getting involved pages to help people getting involved, after some more research, these initiative pages should also support that goal.

Comments on the mockup in #30

2) What would be more useful than a progress bar is an initiative status. Is it Active, Postponed, Complete? Is Active & seeking new contributors? Or is the project winding down? Also, it's darn difficult to guess what % of some of these projects is.

4) A long winded description is probably a waste of space when this page should be communicating progress and how to get involved. I suggest moving it below or a 'read more' link or maybe a summary/overview that appears at hte top, with the long-winded info (probably with links to issues that sparked the whole initiative off) goes below the more dynamic info.

5) I'd relabel this "Project leads" or something. 'Top contributors' suggest there are game mechanics at play, i.e. that the more someone contributes, the higher they'll appear in the list. As you say, it will be editable only by the initiative owner(s). Seeing who else is involved is also really interesting (Heather mocked this up in http://drupal.org/node/1288378#comment-5026186)... people want to work with the people, esp if they're friends. See also http://en.wikipedia.org/wiki/Social_proof :)

Another thing to nail down... d.o. usernames for sure, but possibly also full names?

7) I'm curious about the News strategy. Will it be posted elsewhere like front page of d.o. ? Or is it meant to remain with the issue? Or is there going to be an Initiative News feed somewhere? In a forum? Cos generating additional content that will go stale, just for the sake of it, isn't ideal. ;)

9, 10, 11) I agree with yoroy that these are distracting here. This page needs to be focused on the current initiative.

12) I'd like to see Project Planning appear above News and General Information

13-15) Rather than all the charts, how about a count of issues with their status? e.g. active (2), needs work (3), RTBC (1), closed (10) etc, with links to the list of issues matching that... I'd be great to see a list of all issue that need work or are RTBC.

V. excited by this :) Great stuff!

Not very belpful I know, but just wanted to say a big ++ to this effort!

subscribe. this is awesome.

@bryanhirsch: Stop subscribing, start following

Here is the latest mockup based on the discussions we've been having at BADCamp. Lot's of changes, so I had to re-number everything. Here are the new annotations:

1. Title and custom image - same as before, just a way of personalizing the page
2. Initiative Status - Added the ability to include some tag-like functionality that can be flexible at providing more information around the progress and needs of the initiative. You could have tags like "on hold" or "recruiting members" or "on fire!"... just some ideas.
3. General Information - I just shrank this down. We only want a few sentences and a link to see more if we want it.
4. Get involved - I redesigned this a bit based on lisarex's feedback. Clear labels, clear way of joining the initiative, clear way of getting updates
5. Announcements - this used to be "news". I shrank it a bit. There has been debate on the usefulness of this, but webchick brought up the need to have more static announcements available.
6. Recent activity - slightly redesigned to mat other directions currently being taken on drupal.org
7. Upcoming events - same as before. Working out how to get this on drupal.org
8. Project planning - Added some general info about the issues associated with the initiative. Also, changed the language around iterations as there was confusion about this concept. All the vertical tabs represent are "buckets" of issues. People can organize them however the feel is best.
9. Leadership - changed the title of this block and minimized the information. Just a pic, name, and title. The initiative creator should be able to specify the titles.
10. Initiative Members - a tile list of images representing random initiative members.
11. Project activity - same as before, just in a new place
12. Project Burn-down - changed the name to be more representative of what this graph should show. "Velocity" didn't make much sense.

Feedback appreciated! Webchick is getting started on this soon.

Some additional feedback, I am bit unsure whether I should comment on the actual visual level. There are a number of things that are organized incorrectly and or to prominent.

In terms of functionality:
1. Custom image is a nice idea - but I don’t think we should include this in the initial scope. I don’t think any of the initiatives have images so far, and I am not sure we have the community to really push this kind of idea.
2. We should really think what these tags are, this should be consistent and clear. Something like seeking volunteers applies to almost every initiative.
5. Should this be like news headlines?
6. I don’t like activity is above, project planning. Activity is usually far harder to comprehend.
11,12. Great to have graphs, to allow for easy comprehension of the initiative. But I am definitely not convinced, that they have this value - we need to have clear understanding what the metrics are that will be used to determine this, and how possible it is to do this. Again, looking at the scope I don’t think we should prioritize this.

maybe we could move 3. general information to the sidebar

Hey peeps,

I've taken some of Chris's ideas here and simplified a bit, feedback is welcome :)

Goal for this is to let the community:

• see at a glance how the initiatives for D8 are doing across the board, where are we in the grand scheme of things
• see who's in charge of the initiatives, and their contact information, links to their resources
• scrum-style notes -- what did we do, what are our blockers, what's next on our plate (1 or 2 critical issues for the community to pounce on
• upcoming events

I really just want to be able to communicate general progress, yay we did stuff, and this is stuff we *NEEEEEED* to do.
(you can also view it here)

Nice work dude!

I like having the 4 phase gates at the top - both because it's somewhat of a standard and also because I think that separating development from deployment into D8 is a good idea.

Glad you're running with this! Let me know if I can add anything more.

Yay! I think Angie and Dries also had a point when they said that Deployment is a bit ambiguous -- I just didn't have time to update lol.

So there are 2 options: Discover/Design/Dev/Deploy OR Discover/Design/Dev

if anyone wants to comment feel free, otherwise, we'll do what we think best :)
-s

Detailing is a good one for that fourth phase, but agreed we can (should) postpone on that for now. Gabor and I discussed this page a bit in Denver. I only have a very rough sketch from that, but the gist of it is similar to svettes latest mockup. Only addition would be to maybe have a rough timeline go with those 4 phases, with august 2013 at the far right.

The 'Scrum notes' part looks quite undefined to me still. If people could only write as briefly as the filler text there suggests :) Have we checked if all initiative leads want to be up there with pic and all that contact info?

Maybe only 1 upcoming event per initiative + ical link is more realistic.

Good progress!

@webchick, @heyrocker, etc. spend a lot of time convincing / communicating to people that the official initiatives are not all there is to Drupal 8. Dries took a great deal of his time at the core conversation in Denver explaining that the initiatives are more like marketing tools to communicate to the outside world that we do these big changes (they also proved to be good drivers to get change happen, but that is a different question). However, Dries also pointed out that there are many things that should naturally happen, like performance improvements or UX. If you look at the actual action happening on http://drupal.org/node/3060/commits (the actual changes getting into core), you'll see there are many other things going on. If you look at the issue queues, you'll see big scale theme system changes planned, big Entity API changes planned, etc.

So all in-all, we need to decide what we want/need to do. This issue is about community initiative exposure and I know @svettes, you are clearly focused on that. However, that is not all there is to it for Drupal 8, so if we build this we still need (IMHO should) build one layer up that explains Drupal 8 overall. What I had in mind for a Drupal 8 landing page that would make sense now is at least leading with the following:

I don't necessarily think that leading with big status indicators about the official initiatives gives a good indication of where things are overall, I think we can do those as part of the initiative boxes/sections on the page one by one. Again, there are lots of things happening outside of the initiatives and we just cannot / should not ignore that. Ideally this page would display a graph of activity, lead to commit lists, segments commits as they relate to the initiatives, etc. but that might be daydreaming, and we should look for something implementable ASAP :)

What I think we really need is a one page overview of (a) oh these guys are working on the next version (b) what is the timeline for development (c) can I still get involved (d) who to talk to, which meetings to go to if I'm interested, etc. The lower part of the screen can look like the lower part of your mockup with status more moved down there instead of being a one stop health indicator. I'd also include things like the core mentoring/office hours, core sprints, etc. in the dev calendar, as well as the "major initiatives" list, also giving a chance for big community movements that have legs to be there (such as the entity API / document oriented storage work). I don't think we need to have this an official initiative only page.

That is my high level feedback. I also have various ideas for the detail of information about each initiative / major work area, but don't want to mandate people do all kinds of crazy stuff, so not sure we can go anything more than a static blurb about each that is sometimes updated.

I'd try to avoid progress bars. They don't give a sense of progress to me since they don't provide any indication of velocity. A progress bar can be in the same position for weeks and then jump ahead a good amount (or even back).

For Drupal 7 some guys (sorry I don't remember who) did a progress page (not hosted in drupal.org) with a nice chart (scrum style) with the number of critical bugs and a linear/logarithmic estimation for when the number was going to be 0. It really gave a sense of both progress and velocity.

I'd try to do something similar since that page became very popular.

@Pedro: was that a reference to the dots on Shannon's or on the timeline in my mocks? My mocks have a *timeline*, which just shows the major time points in D8 development forward. Milestone dates, etc. It does not necessarily need to be dynamic, and it would definitely not show any progress per development, its just timing information to let people know when to expect what.

@gabor, several of the previous mocks have progress bars. I thought yours was also a progress bar (because it looks like one :-) but if it is a timeline with a constant progress by date then it may be useful.

Pedro Lozano: you must be talking about http://drupal7releasedate.com/graph.php

@webchick: drupal.org can do blocks. I think we can put some special blocks there above or below the main content to expose more advanced content. Also, a calendar block can go into the sidebar too. I know some drupal.org maintainers might have bad nights (and days) if we include a direct google calendar JS widget in the sidebar, but in practice, it is pretty darn easy to ember a google calendar widget in a page: http://www.google.com/webelements/#!/calendar For the timeline I had something more shiny in mind. I did not find something very close, http://anotherubuntu.blogspot.com/2009/11/lucid-lynx-timeline.html is more shiny, but definitely demonstrates the time, milestones, etc. It can be an image (block) we put on the top of the page.

Hi everyone,

Jumping back in here...

here's a summary of feedback:

- layout needs improvement b/c it looks overwhelming, want to keep the page editable by multiple people, full HTML is out then, which = simple layouts, possibly with less information to simplify maintenance

- would be nice to have a timeline for the general project, but not for individual initiatives. Gabor's timeline thing looks very cool, I dig: http://anotherubuntu.blogspot.com/2009/11/lucid-lynx-timeline.html

- don't like the idea of a status bar for individual initiatives b/c the status changes too much to be relevant.

To do's:
- need initiative lead OK for posting their contact info/photo
- need feedback on Angie's layout here: http://drupal.org/community-initiatives/drupal-core
- need to confirm maintenance of the information (who/frequency)
- need someone to volunteer to make this page look better using filtered HTML (layouts, images, including gabor's timeline thingy)
- need to make a decision about calendar blocks (see below)

Here's my feedback on your feedback :p

- Yoroy

Sorry but I'm not getting the gist of your image there, looks like you're grouping updates instead of separating them out by initiative? WRT scrum notes, should be like this example for each initiative:

Status:
- We finished a new patch for review! [link]
- 2 new peeps are contributing, thanks [names here]

Blockers:
- We can't move forward until *someone* decides to hammer here NOW [link to issue]

Next steps:
- When we get this issue done, we will have some real progress to report: [link]
- We also need several willing souls to work on this ASAP: [link]

Purpose of this: To draw attention to one to four critical issues per initiative so people will get involved and drive progress.

- Gabor/Pedro about status bars
About status bars... Bottom line is, people need to know "how we're doing" in rough terms. They just do. Our audience here is more than just people wanting to work on the initiatives, it includes everyone else who just want to know what in the H-E-double hockey sticks is going on.

Not talking about general status would be a big mistake imho. But I'm not a fan of status bars either. I prefer phase gates (in this case 3 for now: Discover/Design/Develop), and some indicator of how far along you are in those gates.

Anyone want to give some more feedback if this people think this is a huge mistake & I'm all wrong? (which is OK to say, nay, encouraged!!) If you speak out, we'll come up w/ something else :)

- Gabor about calendar
We'd need an individual calendar for each initiative, which is doable. But, doesn't exist atm :)

webchick: Or only listing a select number of initiatives and giving that select set of people Full HTML access. I've already got Full HTML myself, for instance.

Webchick: WRT maintenance, as I see it there are 3 options, I think option a is best:

a) Initiative Update Delegate
one person identified per initiative to:
1) post announcements for meetings/sprints/etc on d.o
2) do meeting minutes after meetings and post to d.o
3) update the D8 page we're talking about in this thread when news breaks

Benefits: One person who is in the know per initiative and who is specifically in charge of that initiative's coms means proper attention will be paid and less hassel for the leads who need to do other things.

Cons: Need to find some people to do this, but I think that's entirely possible.

b) D8 Coms Person only
one person who will post scrum-notes after our bi-weekly meeting to this page for all initiatives.

Benefits: I could probably do this, so less time scrambling for someone to do it. We could make the page full-html since it limits the people who could update it.

Cons: Initiative leads are still in charge of the other coms tasks like their meeting minutes, posting about activities, etc. Since our meetings are bi-weekly perhaps the news will be less frequent than w/ option a

c) D8 Leads are in charge of their own coms
Each lead needs to post their info for meetings/sprints/etc, meeting minutes, and update the D8 page in addition to the other tasks on their plate. I don't like this option b/c it seems to just add 1 more thing for them to do... option B is probably easier for them.

Another idea I was kicking around = twitter. If the leads could hashtag an update, and someone knew how to pull in the latest 3 with the hash, eg: #wsccistatus or #wscciblocker, and stick it in the right place... might simplify the update process.

If peeps have any other ideas, let me know!

I have no problem with Shannon being the go-to person for initiative messaging, but I think "random passerby volunteers getting Full HTML" is a bit hyperbolic. No one suggested blasting it wide open to anyone who asks.

Hi all -

lisarex pointed me here as a place to add a suggestion that occurred to me - it'd be great if we had a consolidated list of all office hours across the project (docs, d.o, core, initiatives) for both people wanting to get involved, and people scheduling online meetings/office hours not to overlap if possible.

jhodgdon flagged for me that there is already a filterable calendar on g.d.o eg. http://groups.drupal.org/events?field_event_type_value_many_to_one%5B%5D... and that if everyone posted them there and we had an "office hours" category that'd make it easy to at least link to.

Ok, so I'm not sure we want this issue to be driven away so much from its original aims, so maybe we want to move to a different issue (a "talk page" so to say about the D8 page I think). I made a nicer timeline and I believe several improvements to the page.

1. Moved the title up. Instead of the more generic title, have the D8 message up front. It looked useless to have a very generic title up front and then the D8 thing buried under several "navigational/informational" parts of the page.
2. Replaced timeline that needed manual editing with more useful/more visual, hopefully more professional looking. Also pointing out that it is planned, not 100% set in stone.
3. Removed textual date list, now that we have on the image. That was only for "accessibility" purposes with this, and I can also easily imagine people want to know about what Feature freeze is and what Code freeze is, which are also all explained on Dries' blog (to some degree), so better to just link there overall.
3. Added short text on core dev structure to explain why this page is mostly about intiiatives. But I clearly *want* this page to have some list of other major initiatives (grassroots stuff), likely in a much more abbreviated way then it has for initiatives but much more useful then it has for the subpages, which are mostly outdated.
4. Retitled the intiiatives status so it does not say it is for D8 core as-is anymore.

A. I think we'd be better served if we get rid of the sidebar on this page, because it is very distracting. Maybe it would be best if this is not a root page in the core handbook structure after all but is its own page instead.

B. I also dispute the usefulness of the initiative status overview as-is. Maybe we want to include it with each initiative in a little box? (yeah I know we don't want ful HTML, I know we can figure this out :)

C. I did not go down deeper into the page but I think the concrete initiative stuff also needs several improvements, but it would be good to figure out A&B first :)

I want this to rock! Let's do the best we can within our limits :)

Hi all, Back w/ more summary & response...

So latest news is:

• Who Maintains: I think the comments agree that while looking for more bodies, I should maintain scrum notes on this page. Long-term goal: a person per initiative. In progress...
• Arian K suggested 1 stop shop for all meetings-- This exists in for D8 initiatives in the form of a gcal, does anyone know if this can be incorporated into that list? Perhaps it's smarter if we should put it into the the one Ariane linked to one and scrap the current one on google?
• Layout: Changes to layout proposed by Gabor -- here's my .02
• Ok w/ all but: not weekly updates, but bi-weekly (2x/mo), and I think having the opportunity to say "we did this, this is where we're blocked and this is where we need you next" is critical to the goals of this page. I really don't want to lose that.
• I think axing the sidebar would be good. What purpose is it serving really when all the links we want people to click on are under the thumbnail anyway

Ok, http://drupal.org/community-initiatives/drupal-core got two of its special doc blocks removed. I'm not 100% sure about the page status block, left that in for now, but it is definitely not the 1st top thing we want to tell people about. Added a block with a google calendar widget of the D8 calendar. The g.d.o calendar that Ariane linked to does not allow repeated events which was/is a continued pain point for scheduling often repeating events. Also, it does not let us embed it anywhere unfortunately :/ So until someone builds those things, not sure what is better, not having any direct indication of those events (dynamically) or having them via a google calendar proxy. We can sign up the google calendar to the groups.drupal.org ical for example as a way to make it embeddable.

Anyway, added the current D8 calendar for now in a block. Wrote some text above to make IRC appealing to newcomers :) "Various working groups hold meetings all throughout the week. Drop by on their respective IRC chat channels to get involved. IRC chat is easy, read more at http://drupal.org/irc.".

I don't know about the rest of you, but I think aside from a little theming, this page is looking pretty decent and a V1 is ready to be used after we clean up the UI a little bit. (The data for CMI looks totally scrunched.)

Who can clean up the UI a little so there's more spacing between the 3 columns overview/scrum notes/upcoming events?

After that, can we start using this? Next meeting is thurs, I'd like to plug in the info then if possible!!

-Shan

Who can clean up the UI a little so there's more spacing between the 3 columns overview/scrum notes/upcoming events?

Actually, the scrunchiness is due to a lack of width: 100% on the table. However, if you actually put in some real text that forces the table to 100% you wind up not needing the extra CSS.

I went ahead and added some lengthier sample text in CMI section and I think it looks a lot better. http://drupal.org/community-initiatives/drupal-core

What of this needs to be considered (or reconsidered) after the D7 d.o upgrade?

What will it take to close this issue?

Just moving projects.

Part of overall content strategy recommendations to address this issue is to implement 'initiative' content type as a tool to manage initiatives, track their progress, etc. These will be part of the upcoming 'Contribute' section. I am sorting issue for now, will add more specifics about proposed new content type shortly.