codetriage / codetriage Goto Github PK

A process question:

I received rspec/rspec-core#616 for triage today. As of this question, the latest comment is two months old. That feels stale to me. On the other hand, there was a meaningful conversation going, so it's not that the issue was simply ignored.

Things I can do as a triager:

1. Bump the thread by saying, "So, where are we on that?" That just seems annoying, although perhaps the maintainers would find it useful.
2. Contribute something interesting to the conversation, only I happen to have nothing interesting to say about this.
3. Ignore the issue and risk letting it get lost. It'll come up again for triage, but the next triager will probably also ignore it, unless it's really, really old by then.

So my questions are:

• What is the right thing to do in this case?
• Is the answer to that question dependent on the project and maintainers, or is there an across-the-board rule of thumb?
• Can we change the triage instructions so the next person doesn't have this question? Or, if it's project-dependent, will custom triage instructions (#31) solve this for the next person?

I'm raising this as an issue not so much because I need help triaging this one RSpec issue, but because I want to make sure the triaging process is as clear as possible for new people.

/cc @dchelimsky on the theory he'll have some insight.

Thinking Stack Overflow newsletter style with an issue for each of the repos a user is subscribed to, as well as maybe some metadata about each issue like up to x words from the description, comment count etc.

Thinking will have to move triage email sending into User model, find_each users, then add an issue to the email for each repo_sub for given user.

I'll happily submit a PR for this when I have time later this month if everyone is happy with it.

After logging in, codetriage.com has a link to http://www.codetriage.com/repos/new, which I assume is the correct submission url.

However, I just get the 500 error ("We're sorry, but something went wrong.") when viewing this page. Apologies if this is the wrong place to report this.

Greetings,

I had a similar problem to issue #96 Can't Sign in. The sign up only checks for the email in your github profile to be non-blank.

flash[:error] = no_email_error if request.env["omniauth.auth"].info.email.blank?

Would it be worth the effort to add a check for a non blank but invalid email address? The validation of the email string is potentially a non trivial task with limited returns.

Is this a task worth investigating further? or is effort better spent elsewhere?

I'm really interested to see who is subscribing to hotsh/rstat.us. I'm trying to put into words why... I might just be curious :)

I suppose I'd like to be able to do outreach if people have been subscribed to rstat.us for a while but haven't contributed at all-- they showed interest in contributing but haven't for some reason, and I'd like to know if I could do anything to help get them involved.

I'm very very interested in bringing new people into open source and would love this as a potential way to reach out to people :)

when trying to add my repository here http://www.codetriage.com/repos/new , tab "Your own repositories".
For ex. https://github.com/chorny/Text-ParseWords is not shown, but issues are enabled.

I always get "We're sorry, but something went wrong." when I try to sign up. Codetriage is now listed in my authorized apps on GitHub, but I can't sign in / up

When clicking the "Back" button on my user profile page, I get an error saying that the page does not exist.

Clicking the "Back" button leads to /users

I changed my email, and the data was updated, but there was no acknowledgement. From a UX perspective, I either wanted the submit button to redirect to the show view, or to flash a message that my update was saved. But here's the update method from the controller:

def update
    @user = current_user
    @user.update_attributes(params[:user])
    redirect_to :back
  end

Shouldn't redirect_to :back go back? It's not working.

At http://www.codetriage.com/repos/new, in addition to seeing your own repos, it would be nice to see repos you've starred on GitHub, as you're likely to be interested in triaging them.

The same may be true of watched repos, though perhaps you're already so engaged that you don't need to use Code Triage. Opinions?

I'm up for writing the code; this is a placeholder for early discussion.

Hi, I'm one of the maintainers of hotsh/rstat.us, currently #10 on the most issues list ;) I LOVE this project, and I love new contributors!

Have you considered having a way that maintainers can say that they're open and welcoming to these kinds of contributions? I've heard and had the experience that jumping into an OSS project that you're not familiar with can be intimidating when you're not sure of the project's culture.

Maybe a note from maintainers on the page? Perhaps even allow maintainers to customize the email with instructions? I totally understand if this is out of scope of this project though :)

I've been occasionally working on and thinking about how to get more people into OSS, and I really like the concept of this project :)

I just had an email for an issue closed a few hours ago.

Hi

I'm having some problems logging in to codetriage.com. When I click the sign in button I just get a standard Rails 500 error ("We're sorry, but something went wrong."). It doesn't matter if I'm logged in to GitHub or not.

http://www.codetriage.com/symfony/symfony

Says there's no tickets but going to https://github.com/symfony/symfony says there's 544 issues open.

If you head to http://codetriage.com, sign out if you're signed in already, then click "Sign up" from the nav bar, you'll get redirected to http://issuetriage.herokuapp.com/?error=redirect_uri_mismatch

I think the callback URL for the Github Application has to be updated to codetriage.com, but maybe it's something else.

Is anyone else getting emails referencing the same issue multiple times?

Both unsubscribe links in the email do not seem to work at all. They just take me to a blank page that doesn't seem to have anything on it.

Email Links:

Blank Page:

This is really frustrating, as it is just a dead end and I cannot successfully unsubscribe.

Once you have signed in there is nothing that indicates you are signed in. Sign Up still appears in the top banner, and the page still asks you to sign in using github, but the buttons don't do anything.

The unsubscribe links currently take you to your profile page and is a several step process (including remembering a password and logging in) before you can complete the task.

I've tried this in a wide variety of browsers, but even after clearing cookies/cache and re-authenticating with Github. I can't see to sign in.

Is there some step about authorizing codetriage as a Github app or something that I'm missing?

We need to check that we are not already working on an issue before emailing it to someone.

With the smaller projects, there's a greater chance we're already involved on an issue.

Nowhere in the notification emails is there a link to CodeTriage.com to modify triage settings. Having a link might be a nice convenience especially if someone forked CT and should have a customized email notification.

Discussion about this started in #80

May be users can choose between :

• actual default email behavior #98
• daily digest mail
  • only a list of link to issues per repo
• weekly digest mail ?
  • same as above but weekly \o/

Just run rake

  1) Error:
test_the_issue_for_triage!_for_new_user(RepoSubscriptionsTest):
NoMethodError: undefined method `issue_for_triage!' for #<RepoSubscription:0x007fa64543ba50>
    /Users/parndt/.rvm/gems/ruby-1.9.3-p286/gems/activemodel-3.2.6/lib/active_model/attribute_methods.rb:407:in `method_missing'
    /Users/parndt/.rvm/gems/ruby-1.9.3-p286/gems/activerecord-3.2.6/lib/active_record/attribute_methods.rb:149:in `method_missing'
    /code/issue_triage/test/unit/repo_subscriptions_test.rb:16:in `block in <class:RepoSubscriptionsTest>'

  2) Error:
test_the_issue_for_triage!_for_user_with_existing_issue_assignments(RepoSubscriptionsTest):
NoMethodError: undefined method `issue_for_triage!' for #<RepoSubscription:0x007fa6447afd68>
    /Users/parndt/.rvm/gems/ruby-1.9.3-p286/gems/activemodel-3.2.6/lib/active_model/attribute_methods.rb:407:in `method_missing'
    /Users/parndt/.rvm/gems/ruby-1.9.3-p286/gems/activerecord-3.2.6/lib/active_record/attribute_methods.rb:149:in `method_missing'
    /code/issue_triage/test/unit/repo_subscriptions_test.rb:41:in `block in <class:RepoSubscriptionsTest>'

Error on: http://www.codetriage.com/hotsh/rstat.us/subscribers

Looks like a routing bug?

2012-12-04T00:38:05+00:00 app[web.2]: ActionController::RoutingError (No route matches [GET] "/hotsh/rstat.us/subscribers"):
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/rack/logger.rb:26:in `call_app'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/rack/logger.rb:16:in `call'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/request_id.rb:22:in `call'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/methodoverride.rb:21:in `call'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/runtime.rb:17:in `call'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/lock.rb:15:in `call'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/static.rb:62:in `call'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:136:in `forward'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:245:in `fetch'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:185:in `lookup'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:66:in `call!'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:51:in `call'
2012-12-04T00:38:05+00:00 app[web.2]:   vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:479:in `call'

User references #name attribute at one point, but it doesn't exist for the model. Assuming we want to stick with it, just needs a migration.

Repos like Gittip's which name is a domain produce a The page you were looking for doesn't exist error.

http://www.codetriage.com/zetaweb/www.gittip.com

can there be an option to limit the TOTAL issues per day? I signed up for a bunch of stuff expecting 1 per day and got 15

When I select a tab (say Ruby), and I look at the repos and I go to one and press back, the tabs reset (to Python). Is there a way to save state on that? It's frustrating to try to get back to your place.

For example, is there a way to add a an anchor to the URL when you click a tab, so that when you go back, that tab is still selected?

Someone mentioned they wanted to change the frequency of emails the receive. Once a day, every other day, or once a week. Seems reasonable.

Looks like we need a uniqueness validator

Does it make sense to rename the project itself to code_triage or codetriage now that there has been a name change?

Hello,

I subscribed to triage Kaminari and got the first email instantly. But it's been a few days one and I didn't get any new email. Is there a reason for that?

Thanks

I added the ability to get more than 1 email a day per repo. Change the email_limit field in a RepoSubscription. I set mine to 9 for rails/rails and now I get 9 new rails issues every day.

I haven't made a UI for it. A PR would be appreciated.

Being emailed weekly when you've decided to temporarily not be involved in code triage is irritating and likely to lead to people deleting their account and forgetting about the product.

After the first couple of weeks, it should leave longer between reminder emails.

I notice that after adding a new repo there is no issues listed even when the projects has some issues. So is there a way to manually trigger the check of issues for a particular project or after the project get added that the application retrieve them?

Exception on New Repos Page.

To recreate: submit a repo that you're already subscribed to. I used one of my own, if it matters.

This results in some weird behavior: you'll see the repo show up twice under "Repos you are currently helping", and you'll see yourself show up twice under that repos subscribers.

The application crashes with Heroku error page when visiting :
http://www.codetriage.com/resque/resque

c language links are broken. c, c++ and c# point to c

Love this idea! After playing with it for a little while, I feel like I need to have some specific triage instructions from the repo maintainers. Each project has its own sub-community and without this per-project "induction", it feels a little intimidating blindly engaging with a sub-community I'm not really familiar with.

Thanks! 😃

Hey guys!

Trying to add the jquery repo throws 500: “We're sorry, but something went wrong.” And I get the same if I try to acess http://www.codetriage.com/jquery/jquery, which I’ve tried just in case it’s already registered.

The paging is not working properly.

When the list is filtered by a type of repo, and you change pages, it retrieves the full page and then filters, instead of filtering and then paging. It leads to some strange behavior.

Sign up to receive a random issue from a random repo from a specified language

We may need a new thing in addition to RepoSubscriptions to store this since a language isn't a repo. Also need a way of adding these issues to the daily email.

cc @DanielleSucher

No where in the README nor on github itself is a link to http://www.codetriage.com/

I don't think it's a good thing to assume Users are happy to be assigned to some issue just because it was emailed to them.

Perhaps have a button in the email next to the issue that allows the user to accept the assignment, otherwise assume they're not taking any action.

Another option is to check the comments on the issue on GitHub. If no comments, pretty safe to assume they didn't accept the issue.

README says to run app with foreman start which will read the Procfile and try to spawn a worker, which then requires a Redis instance. Is the worker required for local development / testing, or is just for tasks in Production?

If it's relevant to local development then we should add to the README instructions to run Redis as well. If not, we could change the instructions to use bundle exec rails server or something instead.

Thoughts here?

Upon clicking on Sign in, it displays the standard Rails 500 page: "We're sorry, but something went wrong." I've signed up with this github account.

Thanks!

Goals of Triage
Encourage productive communication

I wouldn't call it productive when I still need to click and open issue in order to get what it says.

Instead of including bulk of text "Goals of Triage" and "How To Triage?" into every email, I suggest you to include short or full description of the issue. Also would be nice to see last few comments with gravatars of users.