Holistic Design Critique for a Volunteer Matching Service I'm a new Drupal developer, and  I made an initial implementation of a project, but some of the things that I'm doing probably aren't the best solutions, so I was hoping to get some critiques of my design.  What the site will do and how I'm doing it is below.

The motivation:

I'm making a volunteer matching service in Drupal 7.  Specifically, community representatives from nonprofits can point our service to their issue tracker (ie, GitHub), we'll turn their issues into nodes, they can organize those nodes, and volunteers can sign up to work on some of those issues.  Also, those volunteers will belong to an organization with a Corporate Social Responsibility (CSR) representative, and the CSR representative can administer their volunteers (email them, modify the tasks that they signed up for, etc).

The implementation:

Community managers are a user type.  I use profiles2 and fields to give them an issue_tracker_url that they can store in their profile.  I implement hook_menu to add a link to their profile that they can click to grab issues from the issue tracker based on their specified issue_tracker_url.  The function that pulls stuff down from the issue tracker is the callback in hook_menu.

"Issue" is a custom node type that has some fields like the issue's id within the issue tracker so that we don't get duplicate nodes if the nonprofit pulls issues multiple times.  

Each community manager can have several projects.  Each project can have smaller sub-components.  The issues from the issue trackers all belong to a given sub-component.  The community manager should be able to manage which issues are in each component, which components are in each project, and which projects are in their organization.  Allowing them to create nodes of each type and organize everything in a book would work, but it seems like a kludge.  Taxonomies seem like they might be a more elegant solution, but I wasn't sure how to get one set up for what I'm looking for or how to let the community managers manage their own organization's taxonomy.  

The volunteers also need to be able to view using this hierarchy.  That is, they should be able to see a list of all organizations (all community managers).  An organization page should have a list of all projects; a project page should have a list of all sub-components; a sub-component page should have a list of all issues pulled from the issue tracker that were organized into that component.  I have tried using a view with filtering, but I haven't found a way to do that so that it will automatically generate pages based on the hierarchy described above.

I haven't yet figured out how to set it up such that the CSR representatives can manage volunteers from their company.

All of this should be easy to setup in case we want to have multiple instances of this service.  Thus, the manual setup stuff involved in setting up the views and fields should be automated.  Could I use the features module to automate this?

I have tried to do as much of this as possible using existing modules for the sake of maintainability, but if any of the functionality that I'm describing doesn't exist well in an existing module, I'm perfectly comfortable programming it myself.

Thanks for reading through my lengthy description and for your critique!
This type of question is very difficult to respond to. It is very broad and potential responders do not know enough about the details to make sense of the best strategies to use in structuring it.  I suggest that you continue expanding the story you have begun here including flow diagrams for how the user would enter, organize and use the information. Since Drupal is basically a big database management system, think about the database structure  that would make sense to hold the information.  

You will contain most information in content types with associated fields to categorize the content.  Fields are often associated with taxonomies which add the benefit of creating organizational hierarchies.  They provide a simple way for users to enter and categorize their information effectively and uniformly. You can also organize taxonomies into hierarchical menus (Taxonomy Menus) so they can quickly access information they require.

Views is basically a UI for SQL queries, so you will use that to retrieve and organize information to meet the users needs. For instance Views can be set to respond to taxonomy menus to arrange complex collections of content.

The easiest and most flexible way to arrange your information on a page is to use Panels and Page Manager(Ctools).  They allow you to intercept any URL request and arrange the content in multiple ways depending upon the context at the time it is called.  For instance, you can alter the content on a page and rearrange how it is displayed based upon the permission level of a user.  By adding Panels Everywhere, I have managed to practically totally bypass the theming system and the complex styling spaghetti it can produce and simplify my style sheets and gain better control of what is displayed.

Features is a great module for exporting parts of a site to other sites.  It is complicated and not perfect, so I would recommend getting one site solved first and deal with features later if you can.

I have had some problems with Profile2 and do not believe it is ready for prime time yet (it is a fairly new module).  Most basic profile information can be easily handled by adding fields to the users entity.

Pathauto will allow you to create aliases for the URL which is very nice for creating user friendly URL descriptions, but bear in mind that views contextual filters do not work with aliases well and cause cause you grief.

You will continue to learn about and pick up on other modules that meet certain needs, but I recommend you start conservative and master the few I have bolded in this answer first. Each of these modules is complex and will require study to master. As you encounter specific questions as \k them and you will probably get more useful answers.

Good Luck.