First of all, you really can't use iD to edit route relations as it doesn't support editing of all the data. Please use JOSM for advanced editing of relations.

Each bus route is represented by a route_master relation. The route_master relation has a name tag on it of "Bus 9: Powell Boulevard". The route_master contains all variants of the route. Generally, this includes at least 1 variant for each direction of the route. For Bus 9, there are 2 variants (one for each direction) and these are route relations that are added to the route_master relation with a blank role.

The wiki says to use for the name on the single route variant "<vehicle type> <reference number>: <initial stop> => <terminal stop>" So for this we have "Bus 9: Portland => Gresham Transit Center" and "Bus 9: Gresham Transit Center => Portland" For the members of the route variant, all of the Ways that make up the route are supposed to be included in order of traversal with a blank role. Following the list of Ways for the route are a list of stops, also in order of traversal. Around Portland, we just put a Node near the location of the bus stop sign with the public_transport=platform tag. Note that this Node is not actually connected to the Way for the road. These bus stops are included in the route relation with role "platform".

Beyond the name of the route variant, there are some other problems with these edits. You've created extraneous route relations for existing bus routes
relation/5498286
relation/5498287
You've used incorrect values for the role field ("Gresham-Portland"). Generally, values for the role field follow the same convention as for keys other OSM objects: lowercase words separated by underscores. In this case, though, the role is intentionally left blank because the order of the Ways in the relation determines the direction of the bus route.

I think the first step is for me to revert your recent bus route changes. We can then discuss how exactly we are going to name the route variations on bus routes and do a better job of documenting this on the Portland wiki page:
osm.wiki/Portland,_Oregon

changeset/33930044

Please stop mass editing of bus routes. These were mapped using the guidelines at this page: osm.wiki/Proposed_features/Public_Transport
Your values for role are invalid as these are not supposed to contain free-form text. Also, generally in OSM we don't abbreviate things.

See also this discussion: changeset/32230005

How do you know there's a survey point in the middle of this parking lot?

I think it's preferable to use highway=service and service=driveway for most of the things that you have tagged as highway=living_street.

I happened to drive by here today. As you are exiting I-405 North, there is a sign that says "Kerby Av Exit Only". After you exit, there is a sign that says "Kerby Ave." On the way back as you are entering the on-ramp, there is a sign that says "Fremont Br =>". Based on the wiki documentation and the generally established OSM conventions, I believe it makes sense to remove the "name=Kerby Ave Ramp" tag on these Way objects.

There's some discussion about ramps currently happening on the talk-us email mailing list:
https://lists.openstreetmap.org/pipermail/talk-us/2015-July/015121.html

The general convention is to leave the name tag off of the Way object for the highway=motorway_link. Instead, this same information is put onto the Node where the motorway_link leaves the motorway in the form of highway=motorway_junction with an exit_to tag. This has already been done for this area on the following Node:
node/40378782

Bickenden, where did you get the name "Kerby Ave Ramp"?

The first thing that jumps out is that it goes against the convention of not using abbreviations in street names in OSM. Generally,all of the various _link roads (such as highway=motorway_link) don't have the name tag.

No problem, I've reverted this changeset in chageset 32768270 changeset/32768270
Let me know if you have any questions about editing the map around Portland.

Hi and welcome to OpenStreetMap. You may not realize, but your edits have been made to the main database. It looks like these points don't correspond to objects in the real world. Should I undo these changes?

It's cool to see people updating the map in New Hampshire. I lived in Derry for a while a did a bunch of OSM in southern NH. I'm out in Portland, Oregon now.

Thanks for updating the map. Here's some tagging suggestions:
The name tag should be just "Red Robin" (note spelling and omission of "Restaurant"). The fact that it's a restaurant is covered by the amenity=restaurant tag.
For addresses like this with a secondary number in addition to the main number, I would utilize the addr:unit tag. In this case, you would have addr:housenumber=1500 and addr:unit=W157.
For the phone number, I would change the "+01" to "+1" in the front part. Spaces or dashes are acceptable, so you could do "phone=+1 603 413 0522" or "phone=+1-603-4131-0522"
It's also useful to add website tags, so for this it would be website=http://www.redrobin.com/
(try to keep the URL to the simplest format as sub-pages on website may change frequently).

I've deleted this from 11435 Sprite Way in Oregon City as it appears that you are no longer operating out of this location.

I've corrected some of your work here where you have paths that almost connect to nearby roads. For example, the ends of the following path now actually connect to the the service road and SW Ash Creek Drive:
way/335959464
See also:
osm.wiki/Editing_Standards_and_Conventions#Junctions

After thinking about this, I made the name tag "George L. Smith Elementary School" and removed the old_name tag. If the building gets repurposed for something else but still retains the sign for the old school, then the name can be moved to old_name. I also added the disused:amenity=school tag to indicate that this is no longer being used as a school.

I haven't heard back about this. Generally, we do not use all capital letters on names. These appear to be just a residential house and garage. I've removed the names on these buildings as the name can't be verified.

I posted on my and there's some discussion there:
@Peter%20Dobratz/diary/35170

We shouldn't be adding duplicate data to the main OSM database on purpose. The "polygon dataset" you speak of is not something that is native the OSM data model, but something that was derived from OSM data. We shouldn't require duplicate data in the OSM database in order to help you weed out duplicate data in the dataset that you have derived from OSM data. Your application should be able to consider OSM data as a whole (Nodes, Ways, Relations). Is it worth posting this on an email list to get some more people to weigh in?