Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

Possibility of creating a new repo for the "Wishlist Document" initiative #322

Closed
detrohutt opened this issue May 19, 2018 · 15 comments
Closed

Comments

@detrohutt
Copy link

Over the past couple weeks @mhdawson and I have been meeting with various WGs and individuals to attempt to further the initiative I proposed in nodejs/mentorship #38 and first discussed in the May 4th commcomm meeting.

In the May 17th Security WG meeting we kicked around the idea of having a separate repo where every WG or strategic initiative could raise issues for items they'd like added to the document. There seemed to be general agreement that it was worth trying out with a few WG's and @mhdawson suggested I raise an issue here for further input or thoughts on if this is feasible.

Unfortunately I missed the recent commcomm meeting where this was on the agenda, but I'll be available for the next meeting if it's still on the agenda. I'd be happy to have the discussion in this issue as well.

@mhdawson
Copy link
Member

Some of the reasons a separate repo could make sense include:

  • Issue are often going to be a wish list that won't get attention unless there is help outside the wg. Therefore having them outside the wg repo means that they won't 'clutter' the wg repo.
  • It would provide one place that people looking of issues that they could contribute to could follow/watch.
  • It would be easier to track the success of pulling in new/outside people to help as this could be tracked in the single repo.

There would be some downsides like potential duplication if the wg wants to track in their repo as well.

@mhdawson
Copy link
Member

mhdawson commented Jun 5, 2018

@nodejs/community-committee any thoughts?

@amiller-gh
Copy link
Member

There would be some downsides like potential duplication if the wg wants to track in their repo as well.

We could possibly leverage an org-wide project board for this. Individual WGs would create tickets in their own repos, and add them to the org-wide project. This allows projects to track the issues in their own repos, surface individual issues without a champion at the org level for easy discovery, and keep any comms that happen on the ticket once someone claims it – they simply move it to the “claimed” column of the project board, or remove it from the top level project entirely.

@Tiriel
Copy link
Contributor

Tiriel commented Jun 6, 2018

I do like @amiller-gh 's idea. But anyway even with duplication it seems like a good idea.

@WaleedAshraf
Copy link
Contributor

I like the idea because I have seen few issues where I think it would have been better to get feedback from more people than just one specific WG/repo.

Problems with creating a separate repo:

  • Usually, if someone opens an issue, which doesn't belong in that repo, we close it with a comment to open in the relevant repo.
  • People (new ones) who are not much familiar with all WGs/Repos would end up more confused where to create a new issue. Which is the right place?
  • People who are subscribed to "Priority Document" will be getting a lot of notifications (for all new issues) and sometimes there will be issues, for which they can't do anything about.
  • Then there is the problem of issue duplication.

I more with @amiller-gh idea of org-wide project board.

@Tiriel
Copy link
Contributor

Tiriel commented Jun 6, 2018

@WaleedAshraf I quite don't agree on some points, as I don't think we're talking about the same thing.

Usually, if someone opens an issue, which doesn't belong in that repo, we close it with a comment to open in the relevant repo.

I don't think I see why this would be a problem. It's not a problem on regular repos, it's just day-to-day administration as I see it. And in that case anyway, we are talking about a repo in which every WG/Initiative of the entire project could create issues to raise their critical problems in terms of help wanted or blocking points actionable precisely in other repos.

People (new ones) who are not much familiar with all WGs/Repos would end up more confused where to create a new issue. Which is the right place?

Well, I think quite the contrary, it would be a great place to redirect people and help them navigate WG and Initiatives. Make it plain that this repo is made for people to browse the issues so they can find where their help is needed, and in the meantime gather information about every WG/Initiative and their purpose. This could be some sort of "central hub" in which we could take the opportunity to describe all the current WGs and Initiatives to help redirect people.

Anyway that's how I see things, and maybe I didn't understood your comment or the purpose of the document proposed by @detrohutt . If that's the case, do feel free to enlighten me!

Cheers!

@detrohutt
Copy link
Author

detrohutt commented Jun 6, 2018

Thanks for the input everyone! One thing I want to make clear is the repo I'm proposing would be primarily for administration of the document (which more recently we've been calling the "wishlist"). It would be there so I can stay subscribed to one repo and be notified when anyone wants a change made to the document (create, edit, remove a task).

The users/volunteers would be directed to the wishlist document, which would most likely reside on the nodejs.org website (I opened an issue with them to see if they think that's the right place for it, but haven't heard back yet).

The entries in the document could potentially link back to the "Wishlist Repo" for further details on each task, but my primary concern with the repo is making it super accessible to the WG's. If it's too much work to make an issue, people will be less likely to add tasks. The whole reason for this is because a lot of WG's are understaffed, so I don't want them to spend a lot of time describing a task in detail that may not even end up getting any attention.

Here's what I had in mind :

  1. A WG or WG member becomes aware there's something they'd like to have (or is blocking progress, etc) but don't have the time or resources to implement right now.
  2. Someone from the WG raises an issue on the wishlist repo with at least a one-line description (name?) of the task as well as who can be pinged/contacted for more info on the task if someone is interested in helping.
  3. I am subscribed to the repo so I get notified about the new task and add it to the document on the website.
  4. Users/volunteers see the task on the list on the website, want to help, and reach out to the contact person for that task.
  5. Later, the original issue can be used to let me know the task has changed or is no longer needed.

I don't see the duplication as a problem. There'd be a clear separation of concerns between the two corresponding issues. Tracking progress and discussion on the task would take place in the WG's repo, and the issue in the Wishlist repo would only be for WG members to notify me of changes needing to be made to the document. I could make that very clear in the repo's README.

As far as using a project board.. I'm not inherently against the idea, but I am currently unfamiliar with using those, and for right now it's just me that will be administrating the Wishlist document that volunteers see. I like the idea of being able to subscribe to one repo and be notified of all changes needed without having to make sure I'm pinged/subscribed to all relevant issues across all node.js repos as they are raised. Also I don't want to be subscribed to the issues where tracking/discussion is happening because it'd create too much notification noise for me to know when it is something that actually needs action on my part so I'd need to be pinged specifically every time an action was needed on my part. Is there a way for me to be similarly subscribed to the project board, and will the steps I listed above still be able to work in roughly the same way with a project board?

@WaleedAshraf
Copy link
Contributor

thanks, @detrohutt @Tiriel for the explanation. I didn't get it right at first.
You are right, there won't be much duplication in this case. Not sure how much effort it would take for you to keep the site updated with new tasks?

Project board is good if it can help you in managing/updating/notif in a better way than the repo.

@detrohutt
Copy link
Author

detrohutt commented Jun 6, 2018

I won't know much about how much effort it's going to be until I hear back from the nodejs.org team, but I'm hoping it won't be much more difficult than updating a Google Doc. If so, I can probably make all the necessary changes to the document with just a few minutes of work each day.

@detrohutt detrohutt changed the title Possibility of creating a new repo for the "Priority Document" initiative Possibility of creating a new repo for the "Wishlist Document" initiative Jun 6, 2018
@codeekage
Copy link
Contributor

codeekage commented Jun 7, 2018 via email

@Tiriel
Copy link
Contributor

Tiriel commented Jun 7, 2018

@codeekage I can't speak for what was intended by @detrohutt , but I'm on the same page as you are.

For me there are two points here:

  • WG/Initiatives could put out issues for which they desperately need people/help
  • WG/Initiatives could put out good first issues, to help recruit new contributors and have a better and clearer way in the project.

And I really like your suggestion on the readme and the tags!

@detrohutt
Copy link
Author

IMO, I don't see a reason to limit it to good-first-issues. My original intention for this initiative was to direct available help of any kind where it's most needed. There's no reason veteran collaborators can't make use of the document as well as newcomers. I think of it like a bulletin board that can help you decide what to work on next each time you complete a task.

I'm starting to wonder if it necessarily needs to be a document or if I could just use the README of the Wishlist repo as the document and direct people to the README. I'm not sure that Markdown can support everything I'd like the document to be able to do, but it's worth considering.

I agree those are great ideas @codeekage so thank you for sharing them!

@codeekage
Copy link
Contributor

@detrohutt the repo will not be limited to new folks, "veteran" collaborators can also help with the issues that'll be open in that repo.

It basically shows issues members of a WG have agreed to let other folks from within the Node.js Project and outside Node.js Project assist on.

So, it creates an environment where everyone is welcomed to help. Be it New or Old.

@detrohutt
Copy link
Author

@codeekage Ok that’s pretty much what I meant. :) Sorry if I misunderstood your previous post.

@detrohutt
Copy link
Author

@mhdawson The agenda label can be removed from this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants