R.J. Steinert

I think that's a great idea Dorn. Using the same Wiki-Forum format we are using for physical tools can also work for our process tools. I vote for moving ahead on this and I want to mention two things to consider as we move ahead. Before getting into the two considerations for this, a quick clarification on the functionality behind Tools. The "Tool" Entity, the thing with metadata like "Stage" and "Type", is the glue that holds together the relationship between a Forum and a Wiki page. In addition to Tool's holding metadata on the Tool and relationships to a Forum and Wiki, there is code I wrote to display all three things on a single page if you go to any one of those three things. Note that we could create a Forum and a Wiki page separately, put a link at the top of each to their counterpart, and the only thing we would be missing out on is the presentation of the Wiki and Forum on the same page. - A "Best Practices" Wiki page and Forum may not be findable on the Tools list Perhaps it would be better suited to be in the General category of the Forum. We could reassign the "Best Practices" Forum fromt the Tools category to the General category. - Does the data model (metadata like "Stage" and "Type") for our "Tools" concept fit something like this? Right now I don't see this as a big deal and it's not necessarily a big deal if we decide otherwise in the future. If down the line we decide that "Best Practices" is not a good fit for the Tool data model, then we delete the "Best Practices" Tool, the Best Practices Forum and Best Practices Wiki page stick around because they are separate entities, and then we create some other alternative to the Tool Entity type that we use to glue the Best Practices Forum and Best Practices Wiki together. My analysis could be seen as a green light to shoehorn whatever we want into the Tools section right now, because after all, if decide something is not a Tool, we don't lose the Forum and Wiki page when we delete the Tool.

I'm loving the discussion here. I'm all for using the tools we have and using outside tools at the same time. There are two concepts I want to throw out there for funding open source research and development. # Bounty In open source lingo, a bounty is sum of money offered for completing a development task that will be open sourced. In my experience this often starts as someone saying in a projects issue queue (a project issue queue is equivalent to a Tool's Forum) saying, "Hey! I need this thing done real bad," and then another person saying, "Ya! Me too but I don't know how to get it done," and then maybe some other people echoing the desire. The folks with the need then get together and dedicate some funds to complete it (or services or whatever) for someone to do it. Because they are talking about it in that project's issue queue, someone who knows how to complete that task and also has an interest in doing so eventually comes along and they strike a deal. w00t! The key here being the proximity of those who need something done and those who can complete the task, a network effect of saying, "Hey we need this, here's some funds," and someone close by saying, "I can do that." # Reverse Bounty Before there was Kickstarter, there was Reverse Bounty. A developer wants to get something done so they say, "Hey world! If you also want to get this thing done then pay me x number of dollars and I'll be able to do that!" The only thing Kickstarter added was a deadline for funding, and boy does that work! I've seen reverse bounties take YEARS.. unfortunately. The deadline creates a sense of urgency, but it also gives folks a sense that they are allocating a certain amount of funds in a specific time period and that matters in the real world where a tool is worth something to you in the next 60 days but might not be worth anything to you a year from now. # My conclusion So if someone creates a Reverse Bounty (Kickstarter)/Bounty to do a production run of a Tool and they mention it on that Tool's Wiki page or Forum, they get that network effect of people with the same needs being close by jumping in.