The structure of the PWGAD organizations would not change, nor is it even a concern for the DOLI. If they are serving as a fiscal sponsor the arrangement simply follows the structure and requirements set forth by PWGAD (or whatever name they may be operating under). The DOLI's only concern would be to complete projects and reporting as required. Details re any ownership issues should be addressed in the agreement, but there are rules that must be followed or the parent organization could lose it's status and receive a significant tax bill.
What are you trying to sort out? What is the specific concern?
Republished as book/wiki for community updateAll these are volunteer positions (and not everyone has even formally assented to their assignment!) so please feel free to lighten the load by getting involved. If you would like to help: add your name, link to your DO profile, subscribe to post from this group (click on your username top-left and select 'Notifications'), get involved.
Team:
Where did we leave off? What/who do we need to update to the now?
Formal Requirements - Kathleen Murtagh
Information architecture - Mitchell Tannenbaum (with participation from Claudina Sarahe and others)
Wireframes - Mitchell Tannenbaum
Design - Romy (Carolyn Hong)
Project manager - Gus, ?
Liason between old/new vision and team - Ben
Creating fully functional protype on this Drupal Kata/Open Atrium site - Gus
Development - Kathleen, Benjamin, ... "the community"
How do we want to present this project to Drupal Community?
This and all 'book' pages are 'wiki' page... please log-in and contribute!
Draft:
Coordinating community initiatives, from the Drupal Bus to the Git migration, is critically important to the health of the Drupal project and the happiness of those who work on it. We believe there is a broad range of potential awesome initiatives between what a few individuals or a company can kick off, on one end of the spectrum, and what calls for the heft of the Drupal Association, on the other end. We would like to make these initiatives more likely to take flight or take root by helping bring people with the interest, time, skill, and resources together.
To aid Drupal people in coordinating community initiatives, we propose the following approaches:
* A monthly conference call with IRC backchannel on community initiatives and what connections might be missed.
* A place for people to describe specific initiatives and resources needed, to express support for posted initiatives in principal, and to pledge in practice support of work and resources, perhaps at drupal.visionsunite.org. Resources includes money and the system should including a means for aggregating funds.
Note: When putting content on groups.drupal.org, let's avoid creating another group. Paying for the Plumbing can be home base. Monthly Conference Calls will be announced as events under this GDO group.
I don't know that it has had a successful fundraising in its history. Asking people to join a group and wait for something they want to fund to be posted is not a very good model. See in any case its questions to answer when starting a fundraising campaign.
Save the Docs: Improve drupal.org infrastructure or host elsewhere old handbook pages, clearly marked if deprecated, and pointing to the best new equivalent, if any.
Flow: User login API (multiple sources for users/roles) and in-line log-in, registration, password reminding. See http://data.agaric.com/node/2321
http://modulecraft.com/ - fund-raising project by Pronovix that aims to rally Drupal professionals around a shared effort to create the ultimate toolset for Drupal business.
Seeder (Built on Drupal 6 for The Cedar, code not yet released)
The Need
Earl Miles states the need to raise funds for Free Software clearly:
It works when your employer uses the software you create. It's a lot tougher when you want to create something that no single employer is going to get enough value out of to justify the total cost.
That's where you want something that allows you to pool customer's money together.
He considers the app store model or the support model or a hybrid subscription model, but sees practical difficulties with both. The possibility of coordinating our needs and funding software development up front needs to be presented here and everywhere as a strong possibility with infrastructure to back it up.
Open source is the best way to build and distribute software. There are few things about which I'm more convinced. In some, but not all cases, Open Source also offers a viable business model. When it does, it's great because it allows you to do well and do good at the same time.
While we could use a Book/Wiki page on this Open Atrium site for our meeting notes, I find it easier to have a shared doc which multiple users can edit at one time. I created the following for the Chicago BOF
This section houses all documents pertaining to the development, design, management, and ongoing support of Snowball. Please note this is a work in progress.
Snowball seeks to help people find one other and to reduce coordination friction, transaction costs, and risks. Part of this vision is driven by the idea of the power of everyone being in one network and so able to find one another based on interest and rely on one another based on skill, availability, and past reliability.
We are here because the [Drupal Dojo](http://groups.drupal.org/drupal-dojo) needed a space in which can manage the Dojo/Kata projects, develop taxonomy, workflow, learning tools and learning content, not to mention managing development sandboxes for a wide range of [Drupal Open Learning Initiatives](http://drupalopenlearning.org). This is the project management and development arm of the Dojo and the [Dojo space in Groups.Drupal.org](http://groups.drupal.org/drupal-dojo)
The [Drupal Dojo](http://drupaldojo.com/about) came from the Japanese concept of the dojo, which means: “the place of the way” and is defined as a training facility. The DrupalDojo.com has provided a centralized location for the development and delivery of open Drupal training.
The [DrupalKata](http://drupalkata.com/) is the project based learning arm of the Dojo. The Kata is able to facilitate a wide range of projects, pairing mentors with apprentices--whether it is two individuals or a project owner and a larger production team. The mission is to develop the projects in the open, identifying learning objectives & milestones, producing lessons and in some cases complete install profiles as projects are completed. The resulting training programs and code would be distributed via the Dojo and Drupal.org.
Ultimately, the work of this group should lead to the open development and refinement of a taxonomy for all Drupal training and a framework that will help organize and reference all learning objects, modules and lessons from problem/solution lightening talks (such as those being presented in the Seattle DUG meetings), to text based tutorials, to recordings of training webinars, to blended learning programs and full blown courses in Drupal design and production.
In order to support the next phase of this work we have established:
a new open atrium Defining Drupal Competencies-book under the Open Drupal Curriculum group -- the pages of this book should remain 'wiki-like' / open for all members of the group to edit; and
This notebook contains 'wiki' (group editable) pages.
These pages may also reference cases/tasks in a 'competencies' project (a grouping of tasks within this group) under the case tracker in within this group. Keep in mind that files can also be attached to these book pages.
Here we'll house all documents pertaining to the building, maintaining, and sustaining of this website. Note that the docs (and site) are currently being cleansed.