Project Management and Github Structure

[legovaer]

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.

[legovaer]

So my reply to @sugaroverflow is:

• We can keep GitHub for our artifacts, but there's a separate issue for that #58
• If we go for a solution which is not on GitHub we can create even a list of todo's with a separate board for every event
• Drupal.org is not a project management tool, it's like GitHub a code management tool. I'd highly recommend us not to use drupal.org for this as we won't get a clear overview of the "project".

[sugaroverflow]

Moving my comments to this issue :)

My personal preference is still Github because:

• I like the way we can compile information in Gitbooks.
• I think the barrier of entry can be lowered by helping people sign up at camps.
• I also see the majority of contributions will be through comments - and not actually taking on full issues (joining the organization) or having to push/pull to the repo. If we are going to move to another PM tool, I would rather move to d.o. Any other tool requires people to create accounts or if it’s completely public, requires us to moderate extensively.

[sugaroverflow]

I think this is now directly related to https://github.com/drupaldiversity/administration/issues/58 now.

[cleverington]

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'.

[sugaroverflow]

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 :)

[cleverington]

Copying from #58

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:

• Start using GitHub "Projects", which can be by Repo (https://github.com/drupaldiversity/administration/projects) or by the entire project (https://github.com/orgs/drupaldiversity/projects)
• Create a new file at https://github.com/drupaldiversity/administration/tree/master/working-docs with a list of all active Google Docs and a small description of each.

[sugaroverflow]

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

General Ideas

• each initiative should have it’s own repo and project board.
• administration repo’s readme should be the landing point for the others.
• global label sets/color assignments
• we can do collaborations with posts in slack during meetings (they're editable by all users) and then put those into the issue queue for the discussion issue.

Label Sets:

- High Level (color)
    - specific (same color scheme as parent)

• Workflow

  • Backlog
  • In progress
  • Review

• Status

  • Needs Help
  • Needs Approval

• Team (Responsible):

  • Communications
  • Technical
  • Meetings
  • Moderation
  • Leadership
  • Project Management 


• (Issue) Type

  • Discussion
  • Idea
  • Task
    • Writing/Editing
    • Planning/Organizing

drupaldiversity/administration

meeting-notes/
assets/
working-docs/
code-of-conduct.txt
README.md

administration Readme page

- 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. 

administration repo labels

• Team (Responsible):
• (Issue) Type

website repo

website files
README.md

Website Readme page:

- 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

Website Labels

• Workflow
• Type
• Status

[sugaroverflow]

Linking issue #58 which discusses how to manage documents.

[sugaroverflow]

I created a visual diagram to get some feedback :)

(NOTE: This is a little different from my outlined proposal above, I removed some things)

[rubyji]

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. ;-)

[cleverington]

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).

[sugaroverflow]

Thank you so much for the feedback @rubyji and @cleverington

I agree with both ideas and will update the diagram :)

[heyrocker]

Just wanted to say +1 to all this, seems like a great starting point.

[bradleyfields]

Great start. +1 too.

Though, Status: Is that represented by color too in this scheme?

[sugaroverflow]

@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 :)

[bradleyfields]

@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.

[sugaroverflow]

@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?

[drnikki]

Hi! So to operationalize this a bit and make sure I understand, we'd make the following changes:

Organization-level

• add book-club repo
• add new-speaker-help (or whatever we're calling that) repo (the planner in me wants to also add a "clone-me-new-project" repo that has everything in it, but I also <3 to overengineer things)

Website repo

• refine doc structure
• add onboarding docs

Admin repo

• reorganize docs
• add this structure
• add team and status labels

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

[AlannaBurke]

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.

[sugaroverflow]

@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.

[cleverington]

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:

• create a repo and link it to GitBook,
• have a configuration file with info like 'book name' and similar metadata,
• have a glossary (which provides 'on-hover' definition for words),
• have a 'SUMMARY.MD', which is in reality the Table of Contents that GitBook reads from to generate the book.

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.

[sugaroverflow]

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.