Closed legovaer closed 7 years ago
So my reply to @sugaroverflow is:
Moving my comments to this issue :)
My personal preference is still Github because:
I think this is now directly related to https://github.com/drupaldiversity/administration/issues/58 now.
I would say I am with @sugaroverflow on a slight concern about adding one more tool to the overall group.
Perhaps for the Leadership and.... Vision / Direction discussions and work (e.g. less than 10 people), I can truly see another tool being useful for Project Management for the group.
The group overall seems to be growing slowly/well via GitHub, including the 'Projects', 'Wiki', and 'Issues'.
I really like the ideas that @cleverington has outlined in #58 - how the project management / DD&I "management" teams can run their agendas and work on a PM tool while the DD&I initiatives are on Github with git books and public commenting :)
We talked about this topic fairly heavily in the Meeting today and the general consensus is to remain as we are within GitHub for at least the next quarter, but expand usage into:
I have a proposal for the structure so we have a place to start from. It might not make perfect sense but this is how I imagined the pieces connecting. :)
Most of this is inspired by @cleverington’s comment https://github.com/drupaldiversity/administration/issues/58#issuecomment-298187411
- High Level (color)
- specific (same color scheme as parent)
Workflow
Status
Team (Responsible):
(Issue) Type
meeting-notes/
assets/
working-docs/
code-of-conduct.txt
README.md
- Intro to DD&I
- link to the FAQ page
- Getting Involved
- Meetings
- Slack invite and channel info
- Calendar link
- Meeting notes
- Discussion/Ideas
- Issue templates
- Administration repo issues tagged with discussion or feedback
- Website
- description of website and general tasks
- link to website repo readme
- Projects
- list of links to the active initiatives and brief descriptions.
-
Initiative Name
Short description of initiative
Link to Github Project board, Readme, and Issue queue.
- Join us!
- Teams:
- description of the teams and responsibilties.
website files
README.md
- How to Setup
- jekyll things
- How to Contribute
- blogs
- technical things?
- Need Help with Git?
- resources
- we might offer help office hours in Slack or quarterly webinars
Linking issue #58 which discusses how to manage documents.
I created a visual diagram to get some feedback :)
(NOTE: This is a little different from my outlined proposal above, I removed some things)
Thanks for the diagram, @sugaroverflow! I'm a very visual thinker. We may discover more as we use this structure but I think this looks great and very functional.
Would it make sense to put the Project readme and tasks inside the Projects box? Also maybe just another project called something like "Etc." to show there will be a lot of them. ;-)
Very well thought out.
From discussions yesterday, you might consider also adding a 'Book Club' project-repo. Currently their issues are in the Admin Queue, which is slightly off-topic (though, of course, very important).
Thank you so much for the feedback @rubyji and @cleverington
I agree with both ideas and will update the diagram :)
Just wanted to say +1 to all this, seems like a great starting point.
Great start. +1 too.
Though, Status
: Is that represented by color too in this scheme?
@bradleyfields Ah, do you mean because the status label is blue and the backgrounds of the squares are blue? If so, no there's no correlation, I'm just not a designer :)
@sugaroverflow Ohh, sorry. I get it now. (Coffee sinking in.)
I think what I was a little unsure about was the separation between statuses and workflow states, and how color schemes handled that. But I'm catching up. Thanks for pulling this together.
@bradleyfields no worries, this is a first draft.
I also struggled with the differences between Status/Workflow - which is why I removed workflow from the diagram. I think Workflow can be achieved with Github projects Kanban board (the To-Do|Doing|Done board) instead of labels while the status label is more for leadership to know what they need to review.
What do you think?
Hi! So to operationalize this a bit and make sure I understand, we'd make the following changes:
Organization-level
Website repo
Admin repo
Is that right?
Would we use the repo wikis at all?
I know github wasn't really designed to support the storage of living documentation for a grassroots organization, but I love that we're giving it a go. <3
I think the repo wikis can be helpful - i was planning to use it, for example, for internal moderation resources and whatnot. but that can be up to teams! i'm just a wiki fanatic.
Question - where will our team-contributed "resources" live? (ie, glossaries and other documentation) On the website? Or in github as a wiki or gitbook (i'm actually not super familiar with gitbooks!) I can see a need for an easily team-member editable set of resources that can be referenced, so I think a canonical DDI wiki would be a good thing to have, but I'm not sure which repo it should live in.
@drnikki that covers everything! thank you :D
@AlannaBurke I agree! I think repo wikis are fantastic for aggregating links or "Getting Started with this thing" guides. I know they're more work, but landing readmes are really useful to lower the entrance barrier.
For our team resources, I think a wiki is a good idea! Or a gitbook like we do for our event organizers packet. I think @cleverington can weigh in for this.
For the resources, I'd recommend GitBook'ing it in the A11Y repo we're going to start working on.
We could also simply create a 'resources' repo with multiple directories.
The only concern I would have with going the route of using repo-specific Wikis is knowledge aggregation for people outside of the group. The... published content, let's say.
I think for internal policies/documentation/etc., the Wikis are great. You can clone them down just like a repo and edit locally, so its easy to create/edit. But for external projects, such as the Organizer's Packet, the A11Y Packet, etc., it would be smoother and allow us a greater level of content-sharing to use the GitBooks and/or the working-docs/ folder in the Administration repo (I really like the idea of a directory dedicated to Speaker resources so we do not keep re-inventing the wheel).
@AlannaBurke For learning GitBook, you basically need to know Markdown (or even just Google Docs) and we can take care of the rest. There's a short-intro tutorial in the Contributors.md page for the Organizer's Packet, if you like. Other than that, GitBook is basically the same as the Wiki, only you:
More importantly, you have the ability to create everything in a Google Doc, share it with me, and I can get it converted to markdown (images and all) for inserting into media.
Made one last structure diagram based on feedback. (Cut back on the labels and added the sample project and readmes)
It looks like @drnikki implemented a lot of this already. I'll do some leftover issue pruning and get to work on those readmes!
Closing this issue for now, but feel free to revisit when necessary.
At this point we are evaluating the future of managing this organization. There were several discussions on both Slack & DC Baltimore and I think we need to make a decision on whether we stick to GitHub to be our PM tool or start using a dedicated PM tool.
We already have a working document.
@sugaroverflow started a discussion inside the document, so I decided to create a separate issue here in GH.