{"action":"created","issue":{"url":"https://api.github.com/repos/cfpb/design-manual/issues/383","labels_url":"https://api.github.com/repos/cfpb/design-manual/issues/383/labels{/name}","comments_url":"https://api.github.com/repos/cfpb/design-manual/issues/383/comments","events_url":"https://api.github.com/repos/cfpb/design-manual/issues/383/events","html_url":"https://github.com/cfpb/design-manual/issues/383","id":123032527,"number":383,"title":"Updated Design Manual structure","user":{"login":"caheberer","id":4739887,"avatar_url":"https://avatars.githubusercontent.com/u/4739887?v=3","gravatar_id":"","url":"https://api.github.com/users/caheberer","html_url":"https://github.com/caheberer","followers_url":"https://api.github.com/users/caheberer/followers","following_url":"https://api.github.com/users/caheberer/following{/other_user}","gists_url":"https://api.github.com/users/caheberer/gists{/gist_id}","starred_url":"https://api.github.com/users/caheberer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/caheberer/subscriptions","organizations_url":"https://api.github.com/users/caheberer/orgs","repos_url":"https://api.github.com/users/caheberer/repos","events_url":"https://api.github.com/users/caheberer/events{/privacy}","received_events_url":"https://api.github.com/users/caheberer/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-12-18T21:52:53Z","updated_at":"2016-01-26T21:53:06Z","closed_at":null,"body":"Hey ya’ll\r\nAs you heard during the last Design Manual meeting. I’m planning to pick up where Daniel’s awesome work left off and lead you into the next phase of the Design Manual. \r\n\r\nI’ve been thinking about an alternative structure to our current format that hopes to address 2 specific questions:\r\n\r\n1. How do we translate the collaboration and, most importantly, focus of our in-person meetings into a remote setting?\r\nand\r\n2. How do we continue to make progress on Design Manual issues, especially the issues that require a large fewd dependency?\r\n\t\r\nBased on the success of the recent addition of the foundational components by each project team, I personally think the best way to make the manual an effective living resource would be to designate a team to not only champion the issues that arise, but also to work on incorporating those new or revised elements into Capital Framework. But, considering we do not currently have the resources to make this happen, I’m hoping the following suggestions might provide us a way to move forward and make progress in a consistent and timely fashion.\r\n\r\nI think we all face the challenge of not having enough free time to tackle Design Manual issues that are important to us, to the completion of our project work, and to the success of our standards as a whole.\r\n\r\nI’m suggesting that we continue to make updating, maintaining (and making our standards better!) a priority for all disciplines. The manual, and specifically the web patterns that make up a large majority of the issues, are important to the team as a whole, not just designers. I’ve gotten feedback from a few team members who are in agreement on this, and that includes front-end developers as well. With that in mind, I’m proposing that we continue to work in a similar format to the larger foundations surge, where project teams incorporate manual work into their sprints. I think this is our only current solution to equally distribute the work and to minimize the overwhelming growth of a fewd issue backlog and to keep our standards up to date. \r\n\r\nSome of you might be panicking right now, but have no fear. I’m thinking that we would distribute just one issue per team and to extend deadlines to once a quarter, with regroups marking the completion of an issue and a time for high-fives. Additionally, to ease the burden on individual teams, I suggest we use Design Manual meeting time to get to work. Issues will be prioritized and assigned by the backlog grooming crew of Ben, Natalia, Scott and myself before each meeting and ongoing as needed. You can help this process by alerting your team leader of important issues during your discipline-specific meetings. And if a project team finds a new issue that takes precedence in order to complete their project work, the ability to swap issues or change priority is an option.\r\n\r\nBack to the meeting time, aside from quick updates from each team and to take care of any blockers at the beginning of the meeting, we would split off in our teams and work via hangouts. If a blocker is brought up that needs large group consensus, we can work as a group for the remainder of the time to discuss and problem solve, otherwise we will break off into our teams. (Using github as usual for documentation and feedback.) Approval will happen in the same method that we use now, using approval tags for design, ui, fewd and 508. \r\n\r\nI’m hoping this will help us make continued improvement and I look forward to trying it out. If we find that we’ve taken care of the majority of the issues, and this level of commitment isn’t necessary anymore, we can reassess a new structure at that time. I’m new to this too, so if it doesn’t work, we’ll figure out something that does. Please use this issue as a place to post any immediate thoughts or questions as well as a place to leave feedback going forward.\r\n\r\nI’m looking forward to continued Design Manual problem solving!"},"comment":{"url":"https://api.github.com/repos/cfpb/design-manual/issues/comments/175249340","html_url":"https://github.com/cfpb/design-manual/issues/383#issuecomment-175249340","issue_url":"https://api.github.com/repos/cfpb/design-manual/issues/383","id":175249340,"user":{"login":"KimberlyMunoz","id":1860176,"avatar_url":"https://avatars.githubusercontent.com/u/1860176?v=3","gravatar_id":"","url":"https://api.github.com/users/KimberlyMunoz","html_url":"https://github.com/KimberlyMunoz","followers_url":"https://api.github.com/users/KimberlyMunoz/followers","following_url":"https://api.github.com/users/KimberlyMunoz/following{/other_user}","gists_url":"https://api.github.com/users/KimberlyMunoz/gists{/gist_id}","starred_url":"https://api.github.com/users/KimberlyMunoz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/KimberlyMunoz/subscriptions","organizations_url":"https://api.github.com/users/KimberlyMunoz/orgs","repos_url":"https://api.github.com/users/KimberlyMunoz/repos","events_url":"https://api.github.com/users/KimberlyMunoz/events{/privacy}","received_events_url":"https://api.github.com/users/KimberlyMunoz/received_events","type":"User","site_admin":false},"created_at":"2016-01-26T21:53:06Z","updated_at":"2016-01-26T21:53:06Z","body":"Tagging @Scotchester since he's our bridge, but raising a flag that we're in the middle of a large month-long sprint to depreciate all our module repos and creating one large repository with a whole docs overhaul. Most of V1 is working on this project, but we're pulling a lot of developers for it as well. \r\n\r\nIt's going to have some impact on the timing of all of this stuff, especially since we might not have a \"home\" for that until our Capital Framework foundational stuff is done."}}