If possible, add https://github.com/emberjs/rfcs/projects/1 to indicate work that a community member could help with.

I'm aiming to put a small table of info on the Community page (http://emberjs.com/community/) to replace the text under the header "In a Giving Mood?". Should be a fairly simple Ajax call on the website ...

@acorncom what is status this project? Active? Cancelled?

Part of ember-learn/ember-styleguide#313

And make it fit better with the overall Ember site?

add ability to filter issues that have both the Octane label AND the help wanted label from the following orgs (specifically, issues that are tagged "Octane Meta" should not show up):

• emberjs (any repo)
• ember-learn (any repo)
• ember-cli (any repo)

Once that is complete, add an Octane filter button to the filter button group.

We need to setup Firebase to enforce security so that non-authenticated users are only able to change the /issues/<issueId>/appPayload/workingOn key. We'll then allow authenticated users (via Github long-term) to update other appPayload values with an admin panel in the future ...

When you load the app, labels display properly next to issues. When you navigate to another category, some labels will not be rendered at all.

It's not clear why this happens. Look into the relationship between issues and labels as API resources.

API Documentation: https://developer.github.com/v3/

Right now, the app pulls Needs Champion and Final Comment Period labeled issues. We probably want to include other labels and pull requests, but it's not clear what the best approach is here.

Talk to core team members about what Help Wanted regarding RFCs should really target, then make those changes.

The builds app has now been incorporated into the new ember-website so we should no longer be showing issues in the help-wanted app

When we launch the ember-website we will do a process of porting issues and archiving the repo 👍 but for now we should stop showing them in help-wanted results

A previous PR made the correct edit of changing the filters out of the navbar and putting them in buttons. However, the navbar content that is displayed on the rest of the ember.js website isn't displaying properly on the help-wanted app.

Screenshot:

Requesting a filter to identify the DecEmber label for the December 2018 Hackathon, so we can better track how many issues we have created and get an accurate count, and so users can look for DecEmber-specific issues during the hackathon.

Part of ember-learn/ember-styleguide#313

We may be better served having the query in the route index.js, which hits github's search api, residing on the ember-help-wanted-server where it can be cached and we don't risk running up against github's api rate limits as easily.

For more info see:
https://developer.github.com/v3/#rate-limiting
https://developer.github.com/v3/search/#rate-limit

This work would correspond with this issue on the server:
ember-learn/ember-help-wanted-server#15

I'm happy to work on this.

@MelSumner @mansona, how does this sound?

Relatedly, I'm noticing that we've been scoping the index route's query to ember-learn repos. There is no language that identifies this scope. Do we want to add language that clarifies or broaden the scope of the query to include other orgs?

Keep in mind that if we maintain the current card-based design of the index page, but expanded out to other orgs beyond ember-learn, this page would grow rather long unless we arbitrarily impose a limit on the number of repos returned by the query.

The query that is pulling in repos on the landing page is not pulling them in appropriately. As we can see in the screenshot, the first repo on the top left is "agendas" (https://github.com/ember-learn/agendas) and this repo does not have any issues labeled "help wanted" - or even any issues at all.

To Fix:
Ensure that the query that populates the landing page is written to pull in repos that have issues with the "help wanted" label on them.

The statusboard app has now been incorporated into the new ember-website so we should no longer be showing issues in the help-wanted app

When we launch the ember-website we will do a process of porting issues and archiving the repo 👍 but for now we should stop showing them in help-wanted results

The app is currently unusable on a mobile screen size. At the very least, the navigation tabs should flow down the screen. If we're feeling fancy, we can add a hamburger menu.

Links to additional points raised in issue #133.

From that issue:

• On the index route's query to ember-learn repos, there is no language that identifies this scope. Do we want to add language that clarifies or broaden the scope of the query to include other orgs?

• If we maintain the current card-based design of the index page, but expanded out to other orgs beyond ember-learn, this page would grow rather long unless we arbitrarily impose a limit on the number of repos returned by the query.

• per @mansona's comment: not all repos are useful right now (e.g. the cards show "forks" for each repo... but that's not really the intent of this app).

• Would much prefer to see the number of help-wanted issues (or rather the number of issues that would show up in our filters).

Things that need fixing:

• buttons are too large and the styleguide size variations did not seem to work (note that we are using the link form of the button by applying classes to <a> (screenshot 1)
• double ember logos look weird (screenshot 1)
• Is it a design choice that cards do not have shadows? We kept the shadows, could tighten them up more
• need some normalizing rules for tables, especially to make th not so bold
• need an "active" state for the buttons
• should use the small button style for "search" once it is fixed

https://ember-help-wanted.netlify.com/core

Failed to load https://ember-help-wanted-server.herokuapp.com/github-issues?group=core: The 'Access-Control-Allow-Origin' header has a value 'https://help-wanted.emberjs.com' that is not equal to the supplied origin. Origin 'https://ember-help-wanted.netlify.com' is therefore not allowed access.

I'm using Chrome 69

If you go to one of the projects (e.g. https://help-wanted.emberjs.com/community), and you click "All Issues" you will be taken to the homepage of Help Wanted, which does not contain issues.

The behaviour should be fixed to list issues for all of the projects instead.

• Allow someone to claim an issue for a week
• Reset that if it wasn't resolved (or didn't have a PR pending, haven't worked through those details yet)

This helps finish off #16

I think it'd be good to copy what Ember Twiddle is doing as much as possible (in the long run we might end up doing a shared add-on or something to make Github auth easier across all EmberJs.com "apps").

Things of interest that seem applicable to what we want to do:

• use Torii (https://github.com/Vestorly/torii)
• setup a torii adapter (https://github.com/ember-cli/ember-twiddle/blob/master/app/torii-adapters/application.js)
• consider using similar config to Twiddle (https://github.com/ember-cli/ember-twiddle/blob/master/config/environment.js#L64-L74)

We'll also want to work out what scope we would want to request for our Github OAuth app. Full details on this here: https://developer.github.com/v3/oauth/#scopes Possible options:

• (no scope) - provides read-only info about the user (basic info, folks probably ok with giving us this info)
• user:email - gives us access to the user's email address (possibly useful for email notifications in the future? what use cases would we have? worth discussing this further ...)
• notifications - not sure this has many practical benefits to what we're aiming to do in the long run

Stars or potentially something else slightly cutesy

The current workingOn should end up pulling from /issues/<issueId>/appPayload whereas all other data will be pulled from /issues/<issueId>/githubPayload

To be shared at workshops or meetups. Doing this would help meetup organizers (and code-school teachers?) run open source nights where items that are currently needed can be hit. It would also allow core team members to bring attention to major items they'd like help with.

• work out UI / messaging around this to make it unobtrusive but easy to find for folks looking for it
• setup Github authentication (#65)
• work through data structures for this (current thought is to have a /lists or /events endpoint with a list editable only by the user who created it). We may also want to have additional fields that a list creator can fill in (brief notes to display above the list that would allow linking out to a UseCanvas file for instance). Make it markdown and fairly short? We may also want to allow a list organizer to make brief notes on each of the issues, allowing them to provide additional detail / thoughts about items and the value of working on them)
• setup authorization rules to enforce the above so that only the user who created the list can edit it
• setup /lists/<username>/<list-slug> routing on the Ember side of things to display the appropriate data
• tests for all of the above

Since the help-wanted app has been integrated into the emberjs.com website, it should use the same navbar as the rest of the emberjs.com website.

Todo:

• use the same navbar as emberjs.com.
• add the filter buttons above the page title (attach the es-button class):
  

Any PRs to address this issue should please include screenshots to show what the implementation looks like.

Currently, the "home" page of this app invites people to click on a nav bar item.

• add content section: "how to get started contributing to Ember" content, similar to what is in CONTRIBUTING.md guides.
• add easily clickable graphics to go to the primary repos/labels
• add an h1 element: <h1>Help Wanted</h1> at the top of the page, between the navbar and the search box (should be inside a <main> element)

Guidelines:

• CSS should be written in a mobile-first way
• try to use ember-styleguide if possible

We'll need to work out how to produce ratings (a rough gauge of how hard an item would be to do) before this can be done. Would love feedback or ideas on how to produce that data (my current thought was to have an approximate number based on which repo the issue is for, but that's pretty rough)

In a mobile-first way, update the CSS for the navbar so it works appropriately on mobile devices.

Issue Description

The current logo is not in line with the Ember branding guidelines.

To fix:

Replace navbar in app with the navbar from ember-styleguide.

• Ember.JS Times
• EmberWeekly
• Ask Tom, other prominent Ember folks to tweet about it

Screenshot:

Change the text of "home" to be "all issues" - we don't want the user to think that this is a second navbar, but rather indicative of filter options.

It would be super useful to know how many issues are currently displayed in the view, especially if I am filtering by a label within a project.

What it looks like now

What it could look like

preferably with a dropdown in place of the "Category" header, allowing choosing only one category instead of all of them.

Might be worth setting up a "table" component to help with this (and with #1 ). Consider https://github.com/offirgolan/ember-light-table or possibly http://opensource.addepar.com/ember-table/#/overview Would probably lean toward the former as it's in a newer, Ember 2.x style ...

This issue is part of our #7 MVP roll-up issue.

I believe we'll want to have an active web hook listening for this payload:
https://developer.github.com/v3/activity/events/types/#issuesevent

Based on that information, we would need to confirm that we're actively tracking this repository and then update the appropriate issue tags in Firebase.

We'll want to handle the following cases:

• closed
• reopened
• labelled
• unlabeled

I have setup a repo here: https://github.com/acorncom/ember-hitlist-tester to help with handling web hook notifications. If someone would like to be a contributor on it so they can add / remove labels, just let me know ;-)

I'd like to help out on this issue:

Problem: The Project name and Title become overlapped when viewed on mobile resolutions.

To do: Update the CSS layout to stack the Project name underneath the Title at mobile resolutions.

Future considerations: The "Project, Title" column headers will not be needed if this is done, and should probably be hidden.

I see some work has already been done on making the app more responsive (ex: Issue #88, PR #96), but if no one is currently addressing this issue, I can start working on it.

Since Octane shipped a long time ago, this category has naturally dropped down to very few issues.

To-do:

• Remove the "Octane" button
• Search this codebase for the word "octane" and see if there is any code to remove
• See if any code needs to be removed in the help-wanted server https://github.com/ember-learn/ember-help-wanted-server and if there is, open a PR for that repository as well.

Right now, this app is on version 4. Version 5 has some breaking changes that need to be addressed. You can read about them here.

To do:

• update package.json to use version 5
• yarn install to update the package lock file
• Fix anything from the list of breaking changes
• See how it looks and make any necessary adjustments
• Commit both package.json and the package lock files, together with your changed files
• open a pull request

Currently, not all repos/labels are showing up when filtered.

If you compare the issues that show up here: https://help-wanted.emberjs.com/learning?label=DecEmber you can see that according to the issue filter code more repos should be appearing in the list.

(Note: this might be an issue for ember-help-wanted-server.)

A recent deploy seems to have removed the project links from the issue tables.

Add a test for this and fix it.

Example:

This app doesn't need end users(a.k.a contributors) to ever signup with their credentials(or SSO). But for folks to claim issues and for us to track if an issue was ever closed due to contribution from that user, we'd need their github handle.

When multiple folks work on a single issue they might want to coordinate over slack/twitter or other channels. This leads to some questions like,

• How do avoid chatter in issues as comments like, hey @siva I'm on the Ember Slack channel to discuss this at @acorncom
• What's the safest way to share their info with each other?

Let us know what you think :)

The list on https://help-wanted.emberjs.com is great, but it would be nice to go to append /issues?q=is%3Aissue+is%3Aopen+label%3A%22Help+Wanted%22 to the URL so it goes right to the issue list.

E.g. https://github.com/ember-learn/ember-help-wanted/issues?q=is%3Aissue+is%3Aopen+label%3A%22Help+Wanted%22

Looks like the important line is here:

And fix anything it says is broken

Part of ember-learn/ember-styleguide#313

using queryParams as well

For this to be a MVP, I think there are a few things remaining that need to be addressed:

• set up a system to receive the webhook notifications (would envision this being a Heroku app in the interests of keeping things cheap / free)
• setup web hook - handling issues based on a few tags for the repos we follow (see below). This will receive the web hooks and handle appropriately. Repo admins will setup webhooks to notify our system. Would suggest that the code for this live in this repo as well (and be written in Node.js / Express) so that we can have everything in one place.
• reworking our Ember app's data storage to use EmberFire / Firebase because we'll need a way to write some basic data (#5)
• fix any broken tests to get all tests passing (#6)
• build a way to "claim" an item (by one or more people). Might need to have this "unlock" after one week to indicate that it still needs help (#10)
• setup Ember Suave (#13)
• add in all Ember repos to be tracked by our web hook (ember-learn/ember-help-wanted-webhook#9)
• get all Ember repos setup to send issue data via web hooks (ember-learn/ember-help-wanted-webhook#10)
• write some real tests (#22)

I just hacked this together quickly to see if it would work