New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project Management and Github Structure #60

Closed
legovaer opened this Issue Apr 29, 2017 · 22 comments

Comments

Projects
None yet
8 participants
@legovaer

legovaer commented Apr 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@legovaer

legovaer Apr 29, 2017

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

legovaer commented Apr 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 2, 2017

Contributor

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

sugaroverflow commented May 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 2, 2017

Contributor

I think this is now directly related to #58 now.

Contributor

sugaroverflow commented May 2, 2017

I think this is now directly related to #58 now.

@cleverington

This comment has been minimized.

Show comment
Hide comment
@cleverington

cleverington May 2, 2017

Contributor

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

Contributor

cleverington commented May 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 2, 2017

Contributor

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

Contributor

sugaroverflow commented May 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cleverington

cleverington May 5, 2017

Contributor

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:

Contributor

cleverington commented May 5, 2017

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:

@sugaroverflow

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 5, 2017

Contributor

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 #58 (comment)

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
Contributor

sugaroverflow commented May 5, 2017

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 #58 (comment)

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

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 5, 2017

Contributor

Linking issue #58 which discusses how to manage documents.

Contributor

sugaroverflow commented May 5, 2017

Linking issue #58 which discusses how to manage documents.

@sugaroverflow sugaroverflow changed the title from Project Management to Project Management and Github Structure May 5, 2017

@sugaroverflow

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 11, 2017

Contributor

I created a visual diagram to get some feedback :)

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

ddi_structure_idea

Contributor

sugaroverflow commented May 11, 2017

I created a visual diagram to get some feedback :)

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

ddi_structure_idea

@rubyji

This comment has been minimized.

Show comment
Hide comment
@rubyji

rubyji May 11, 2017

Member

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

Member

rubyji commented May 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cleverington

cleverington May 11, 2017

Contributor

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

Contributor

cleverington commented May 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 11, 2017

Contributor

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

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

Contributor

sugaroverflow commented May 11, 2017

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

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

@heyrocker

This comment has been minimized.

Show comment
Hide comment
@heyrocker

heyrocker May 11, 2017

Contributor

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

Contributor

heyrocker commented May 11, 2017

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

@bradleyfields

This comment has been minimized.

Show comment
Hide comment
@bradleyfields

bradleyfields May 11, 2017

Great start. +1 too.

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

bradleyfields commented May 11, 2017

Great start. +1 too.

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

@sugaroverflow

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 11, 2017

Contributor

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

Contributor

sugaroverflow commented May 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@bradleyfields

bradleyfields May 11, 2017

@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 commented May 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 11, 2017

Contributor

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

Contributor

sugaroverflow commented May 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@drnikki

drnikki May 12, 2017

Contributor

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

Contributor

drnikki commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@AlannaBurke

AlannaBurke May 12, 2017

Member

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.

Member

AlannaBurke commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 12, 2017

Contributor

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

Contributor

sugaroverflow commented May 12, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@cleverington

cleverington May 12, 2017

Contributor

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.

Contributor

cleverington commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sugaroverflow

sugaroverflow May 13, 2017

Contributor

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

Contributor

sugaroverflow commented May 13, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment