I would like to attempt to use this thread for brainstorming some process improvements for documentation, specifically contributed module documentation. I will try and moderate the discussion by keeping running lists of what's said, asking for consensus or general agreement, and then submit the results as a documentation issue request for final approval. This thread was inspired by another discussion at: http://drupal.org/node/141090. I apologize in advance if all of this has been discussed before and was found to be unwanted.
This is not intended to be a hop on gripe fest. I think everyone is aware that the documentation could use some improvement, however I would like to personally say that I think those who have been documenting thus far have doing a remarkable job. Like I said before, I would like to focus on contributed module documentation.
I has been said in many places by many module maintainers that they just aren't interested in documentation. This is fine, there are many "documenters" who are. There are also many "mental" obstacles to just picking up and documenting someone else's work.
We’ve been playing with how we work with Drupal CVS while setting up our own in-house version control system, and we came up with a rough sketch we wanted to document and share. The ultimate goal is to create a robust work-flow where multiple developers can share code through multiple Drupal-based projects, keeping track of internal changes and also keeping the code up-to-date. We want to track code internally in subversion, while also tracking it against Drupal CVS. We have a method to manually check our code against Drupal CVS that I’ll outline below, but we’re interested in hearing if anyone else doing something along these lines that they might be willing to share.
How we’ve been working
We’ve been checking our Drupal code out of CVS through Eclipse. Besides some issues getting the “-p” option in created patches, we’ve found it works pretty well. We can check out, compare, manage patches all with a quick right click of the mouse. This allows our code to stay up to date. We've been considering moving up to PDT, but we ran into some problems and decided to stay with PHPEclipse for now.
I've got a "regular" Drupal install down to w/i 10 minutes using WHM and PuTTY. But now I really need to take it up a notch and get my server and Drupal configured to accommodate running multiple domains/sites off one Drupal install.
I think my needs/requirements are fairly consistent with those that have gone through the process:
I have been playing with Drupal for a wile, but I still have doubts about why are some tables for.
Do you know if there is a DB tables' description somewhere?
Most of them are obvious, but I have doubts about others... and I'm quite sure there the community described them in the past (as a simple list or an ER diagram...) but I'm unable to find it.
I have E-Commerce 5.x-3.0 running in Drupal 5.1 where I have projects setup where people can donate toward the projects I have setup with target 'goal' prices, but I need the ability for them to either:
a) have a field in the checkout where they can designate what component of the project they want to donate towards
b) utilize the subproduct module to allow users to literally pick a component of the project and add it to the shopping cart