feedback channel(s) for beginners about docs HOT 17 CLOSED

This needn't be an engineered solution. There is supposed to be a Keeper of the Glitches at Installfest. At the opening presentation, s/he should be pointed out very clearly (probably need to add a slide for that -- any takers?). Verbal reporting doesn't require any know-how. It's more useful anyway since many reports need to be understood in context. e.g. The person looking over a shoulder discovers that the problem isn't at step 7, it's that an important detail needs to be clearer up at step 4.

from docs.

That might cover the workshops, but not the case of an unsupervised
installfest or self-paced workshop.  Fine to table or nuke that issue for
now, assuming we get the glitch-keeper re-engaged.  As a vol I was
certainly never told of one, and there have been no updates since the last
workshop, so none of the latest feedback has been incorporated (most of the
glitches reported to me during the installfest were already covered by my
outstanding pull reqs, and the rest I reported in my debrief notes).

from docs.

Keeper of the Updates aka Keeper of the Glitches has been on (either/both) volunteer announcement page and volunteer registration form since March.

Good point about non-local workshops and independent study. I concede that something is needed in addition to communicating to workshop participants about Keeper of Glitches.

Alex (@alexch) is the person to hear from on this.

from docs.

I concede the same point :-)

(but don't know what to do about it)

Sent from my iPhone

On Aug 19, 2012, at 11:36 PM, "Carina C. Zona" [email protected] wrote:

Keeper of the Updates aka Keeper of the Glitches has been on (either/both) volunteer announcement page and volunteer registration form since March.

Good point about non-local workshops and independent study. I concede that something is needed in addition to communicating to workshop participants about Keeper of Glitches.

Alex (@alexch) is the person to hear from on this.

—
Reply to this email directly or view it on GitHub.

from docs.

How about this: a link to GitHub Issues plus a link a mailto:[alex]. And brief text about how using either is swell, yes please tell us stuff.

Hopefully most choose to open a ticket. But there's a alternative for those who want/need one.

from docs.

I like linking to github issues and the mailing list. Maybe put those links
on every page, like in the top where the inscrutable little links are. I
don't want a mailto: to myself but maybe we can make an alias like
[email protected] that goes to a group (or to the railsbridge-workshops
list itself).

from docs.

Okay, if made very clear to the user that they're submitting to a public
list.

It couldn't be the railsbridge-workshops list without rejiggering first.
Only a subscriber can post.

On Mon, Aug 20, 2012 at 12:56 PM, Alex Chaffee [email protected]:

I like linking to github issues and the mailing list. Maybe put those links
on every page, like in the top where the inscrutable little links are. I
don't want a mailto: to myself but maybe we can make an alias like
[email protected] that goes to a group (or to the railsbridge-workshops
list itself).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/91#issuecomment-7881315.

from docs.

I think #1 is making the glitchmeister role clear in the installfest and workshops. More important to get the noobs to raise their hands and ask, when they're on-site with us, so having vols posting to issues (on behalf of noobs, or getting them started) seems like the simplest next step (one slide, one e-mail notice, one link). Then the stuff at least gets a semi-informed filtering, and lands close to where it could get the correct follow-up, thereby producing the least added work. Also threading helps reduce duplicate reports, and encourages collecting missing details.

tl/dr:
I'd say minimal investment in the noob fix for the moment, because I'm more interested in getting intermediate-plus students and volunteers engaged, as a way to give back, get experience, chalk up some pull reqs, and help us model continuous improvement, not to mention expanding the team. Maybe a stepping stone to help cover the gap between the workshop and TA/bridgetroll.

Once I finish my RoR/SaaS class (next 2-7 days) I'll tackle Sinatra so I can finally dissect the site and try to better grok the whole flow. I'll probably do something analogous for BerkeleyLiberationRadio.net (noob guides, feedback channel).

from docs.

Hey y'all — it doesn't look like there's specific action happening with this issue right now, so I'm going to close it.

from docs.

Hi, Lillie.

Just looking at installfest.railsbridge.org, there is still no obvious path for a student to provide feedback. You have to be a volunteer up to grappling with our github workflow to provide feedback and suggest updates for the installfest, and for the basic curriculum there is no hinting (on page one) that there might be any channel whatsoever for feedback. I'm not trying to be ornery, but when I put on my newb beanie and look at what we provide to them, it looks like feedback is not an option (and I think it really should be).

DougM

from docs.

I can reopen this, but there needs to be actual movement to solve the issue. I don't like having open issues sit, not worked on, for months and months and months. Are you going to lead the charge to create a feedback channel?

I don't want the GitHub issues list to be a version of Feature Requests. See:
https://github.com/railsbridge/docs/wiki/Feature-Requests-v.-Pull-Requests

from docs.

There was some discussion on the list about having a simple e-mail destination for student feedback on the docs. Maybe that's the fix for the "bug" and then there's a feature request for something richer.

from docs.

I don't want the GitHub issues list to be a version of Feature Requests.

But unless/until there is a channel for feature requests, aren't you
stifling ideas that could someday turn into Pull Requests simply out of a
sense of tidiness?

Also, what about bug reports? If the bug isn't fixed -- or declared
"wontfix" -- the bug report should remain open.

from docs.

I don't see the point of having an issues list full of things that no one is paying attention to. Maybe I underestimate the degree to which people look here for things to work on, but it seems like unless an issue gets attention fairly soon after being opened, it sits, forever, and with a high number of open-forever issues, it's hard to tell when there are new / urgent / actually-being-discussed issues.

I think having a place for feature requests is a good idea, and that wherever they live should facilitate discussion, but I'm not seeing a lot of connection between discussions within issues and PRs coming in. Let me know if there have been a lot of changes born out of discussions here.

from docs.

I haven't been working on Railsbridge code a lot recently (been teaching
myself iOS -- ugh) but when I do get the urge to dust off an open source
project, I tend to skim the open issues and check for low-hanging fruit.

It would be easy enough to make a wiki page called Feature Requests -- or
better, Feature Ideas -- and when closing an issue, crosslink to it and ask
the requester to elaborate over there.

from docs.

That sounds awesome. Right now there is this page:

https://github.com/railsbridge/docs/wiki/RailsBridge-To-Do-List

and it has a "Curriculum Things" section. Perhaps that page could work for curriculum features as well as the other organizing / communication stuff?

The only problem with this is if people don't know it exists. (That's the major plus of Issues.) But if we link to it real big from the Docs readme, maybe it would work?

from docs.

I just checked the to-do list and it does capture the general spectrum of opportunities, but there's no link yet on the Docs readme. Note to self to scan the updated event and pull-req guidelines, etc., and then attempt a fix that better reflects the current state of volunteer guidance.

from docs.