 |
New Topic Type, the "Problem Statement" |
R.J. Steinert |
Thursday, June 12, 2014 - 9:34am |
 |
Thoughts on Problem Statement and Proposal Summary for Universal Adaptive Management Software |
R.J. Steinert |
Saturday, May 10, 2014 - 3:58pm |
|
|
Fido Logo concept |
R.J. Steinert |
Thursday, March 29, 2012 - 12:16pm |
|
|
Anyone planning on going to the Feb 16/17 NOFA VT Winter Conference? |
R.J. Steinert |
Thursday, January 31, 2013 - 6:11pm |
|
|
We could use a "How to post a video" tutorial |
R.J. Steinert |
Wednesday, December 19, 2012 - 4:07pm |
|
|
Usage/Participation statistics on Tool profiles |
R.J. Steinert |
Wednesday, February 29, 2012 - 12:48pm |
 |
Email bug on FarmHack.net fixed! Check your spam box. Future mail will end up in your inbox. |
R.J. Steinert |
Sunday, February 23, 2014 - 3:38pm |
|
|
A "Farm Hack Stories" series |
R.J. Steinert |
Tuesday, October 2, 2012 - 5:47pm |
|
|
Donate button doesn't work in header |
R.J. Steinert |
Tuesday, March 6, 2012 - 2:02pm |
|
|
Header on Tool pages not wide enough at large resolutions |
R.J. Steinert |
Sunday, March 4, 2012 - 9:36pm |
For those who aren't sure what a PTO is (I wasn't at first), it's a Power Take-Off.
Hi folks. For now, lets try using Wiki pages tagged with "glossary". I created a page that will show us all wiki pages tagged with "glossary" over at http://farmhack.net/glossary. I created the first entry, microcontroller. There are a few other things I'll add down the line:
See my discussion on maintainers. Particularly my last comment on a simple mechanism we could implement now.
Sorry to hear you guys are having troubles. It sounds like this is happening when you: 1. Click "choose file" 2. Select the file from you harddrive 3. Click Save at the bottom of the Form.
Is that correct? It is safer to do the uploading of the file and the saving of the form in separate steps in case the server has a hiccup or your connection is momentarily slow. As a best practice I recommend uploading images using the following steps. 1. Click "choose file" 2. Select the file from you harddrive 3. Click the "Upload" button next to File you just selected on the Form. 4. Wait for the upload to finish. 5. Click Save at the bottom of the Form.
I just performed the first operation I described above on the Root Washer and everything went OK. I did however run into a new bug, if you edit the Root Washer's profile and click "Remove" on the current image, the whole form disappears!
I agree. It's also in the interest of Tool developers that the maximum amount of interested eyeballs find their tools quickly. According to Raymond's version of Linus's Law, "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone." So if we focus on building the search tools for Farm Hackers like myself who are interested in seeing where the action is, then a whole bunch of potential contributors might not be seeing what they are looking for. I think metrics like "# of wiki edits" and "# of forum posts" for a Tool are not first priority but second priority. After the user has somehow generated a list of results they are interested in, the participation metrics let the user know which ones are healthy.
At the moment though and probably for the next few months, I think most people visiting the Tools section will not find anything necessarily useful to them. I think it's important to prove to those folks that if they have a Tool idea and make the effort to post it, that there will be an active community ready to jump in. So for now I'm kind of happy just having the current sort mechanism of "Last Tool Wiki Update" and perhaps when we do get more participation metrics on the Tools page we sort by one of those. Again, this is my thinking for a short term strategy while we are bootstrapping this community. I could be convinced otherwise, prioritizing long term is not that crazy of an idea :P.
For some examples of types of search, check out Section 9, "How will users find information?", in my We believe in sharing document. I think the answer as far as searching goes is giving users a whole array of options. Hopefully we will grow to the point where we need Full Text Search, as they say "a problem we would like to have," but if we implemented it right now it would lead users to a whole bunch of searches with "No results found".
I'm into this idea. We've spent time trying to see into the future and predict how Tools will be categorized, and I like what we have so far, but perhaps now it's time to let users start "freetagging" in a Keywords category on Tools. A tag cloud will show what keywords are the most popular and if we start to seem some category trends in the Keywords vocabulary then we may have a candidate for a new category on Tools. Converting a bunch of content with a set of Keywords into a new category takes a little leg work but it's definitely a problem we'd like to have.
At the moment you can sort on the Stage, Type, and Last Tool Wiki Update columns. I think I can turn that sorting into a dropdown menu fairly easily as well.
I'd love to see this as well and it's high on my priorities for implementation. See the usage metrics I mentioned below in response to Dorn's comment.
In response to
Check out my comment in the Maintainer discussion.
I also just added a "Last Tool Wiki Update" column on the Tools page. Now the Tool with the most recently edited documentation floats to the top. That is at least some kind of indication of activity. Another metric we could publish there might be "# of Tool's Wiki Updates" and "# of Tool's Forum topics". I started with what we have because that was a quick fix. The other two metrics will require an hour or so of coding.
It looks like a good way to start might just be a loose "Volunteer as a maintainer" function on each Tool page that allows users to say who they are and how they plan on contributing. This can be accomplished by just pencilling yourself onto the Tool's Wiki page but it could be massively helpful when sorting Tools to be able to have that extra metadata that shows where people have volunteered to answer questions and where no one has.
Done, done, and done :).
If you go to a user's page, there is now a "contact" tab. See http://www.farmhack.net/user/8
The problem is we're not linking to user pages from anywhere right now. It's going to take a little leg work to modify all the templates that spit out a user's name.
"It would be nice to be able to see who was the last editor without going into the revision history..." Also agreed. Perhaps something near the top of a Wiki that says:
Posted by [username] on [post-date]. Last edited by [username] on [last-edit-date].
Some considerations moving forward with fitting a lot of things into the Tools entity type
I'm not revving to go on my proposal yet because of the reason I mention in the comment linked to above, "...if decide something is not a Tool, we don't lose the Forum and Wiki page when we delete the Tool," but my proposal is one idea on how we might structure things in the future.
Proposal for new forum structure and using the "Forum-Wiki bundle" functionality for everything
I'm not revving to go on my proposal yet because of the reason I mentioned above, " if decide something is not a Tool, we don't lose the Forum and Wiki page when we delete the Tool," but my proposal is one idea on how we might structure things in the future.
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.
BountyIn 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 BountyBefore 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 conclusionSo 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.
Sweet! I pasted that doc into a wiki page. I encapsulated the pasted text with the HTML "pre" tag to get all of the formatting you did with spaces.
Cool! Marking as fixed.
Ok, I found what might be a temporary fix. I turned off the "Convert URLs into links" filter for the "Markdown Syntax and HTML" text format. There might be a way to make the "Markdown" filter and the "Convert URLs into links" filter work harmoniously but for now we'll role without the "Convert URLs into links" filter. We'll look into some WYSIWYG like buttons down the road that will help folks create the necessary markup without needing to remember all of the syntax quirks. For example, there could be a button that you press that then prompts the user for a URL and text and then inserts the proper syntax. It's not true WYSIWYG but this technique makes the learning curve for the syntax easier to climb.
If this is the first time you've heard of WYSIWYG, it's a program that sits inside of a text box on a webpage that makes the text box act like Microsoft Word. Unfortunately it creates nightmares when used for documentation. Things like diffing (comparing) versions of a Wiki page become incomprehensible, you can never get what's in the WYSIWYG to look like what it actually spits out, and if you ever change the settings on a WYSIWYG you risk breaking every piece of documentation when you go back to edit it. WYSIWYGs do however work really well for writing blog posts that you only (theoretically) edit once and then is set in stone.
WYSIWYG example using the LATEX syntax from Wikipedia's page on WYSIWYGS:
Thanks for explaining further Louis. I see there is still an issue with that way of making links at the moment so I'll try to work the kinks out right now.
Tim from Oxbow Farms inspired me to bring it back. It's not the most catchy name (any suggestions?) but I think it's pretty useful. I also added a notice when creating a "loose" Wiki page, "You are creating a loose Wiki page that nothing links to. You will need to link to this Wiki page from somewhere after you save it if you want anyone to find it."
Ah, you just found a bug. I think I fixed it, go ahead and try that link again.
That's a legit issue on my radar. Thanks for reporting it.
Hi you two. Ya, I set the upload limit incorrectly. There was also a file upload but no image upload on comments and an image upload but no file upload on Forum topics. All should be fixed now.
Right now Fido - Greenhouse Monitoring with Text Message Alerts is our most complete example. You can edit Fido's Tool Wiki to see how some of the formatting is achieved. You will also find some good examples over at the Tool section on http://publiclaboratory.com/tools (our #1 influence for the current Tool section). Feel free to ask me questions directly (http://www.farmhack.net/user/8/contact), I would be more than happy to help out and I am working on the website so our discussions may lead to usability improvements for other users as well.
My first shot at a definition of a Tool Wiki:
I like that answer because it describes our collaborative process using Forums and Wikis but it lacks insight on exactly WHAT should bubble up from the Forum to the Wiki.
Before we set any strict guidelines I think we should see what happens, and in doing so, see what works and what doesn't, and I have a feeling that "What a Tool Wiki should be" will depend on the Tool. But, we may be able to start setting a few guidelines as to "What Tool Wiki pages are not." Wikipedia uses a list of "What Wikipedia is not" to help describe what Wikipedia Articles on Wikipedia are http://en.wikipedia.org/wiki/Wikipedia:What_Wikipedia_is_not.
My first idea on what Tool Wikis are notIt's worth mentioning that the use of Instructables embedded directly on a Tool Wiki as opposed to just a link to an Instructable is at odds with the definition I suggested above. Specifically, an Instructable in not the "collective knowledge of a tool that bubbles up from the Tool's Forum". The Instructable is on another site and the owner of the Instructable may be unaware that there is a forum about their tool on Farm Hack where new information is coming to light. An Instructable is also not a "collaborative document" because only the original author of that Instructable can edit it. I make this sound worse than it it really is :P. In my opinion Instructables should ABSOLUTELY be listed on our Tool Wiki pages but displaying it in a way that makes it look like it's part of our site is confusing as to the nature of that documentation. So for Instructables, I think a simple link would to the Instructable suffices.
This leads me to my first suggestion of what Tool Wiki pages are not:
At the moment I'm feeling like we should allow both methods because it depends on the kind of Tool being documented.
Per my first pro points on each model, the former has been proven to work well when developing software where forking is a possibility (forking helps to mitigate the issue of abandonment), the later has worked well for Wikipedia when documenting things that already exist.
That makes sense to me. Louis, if you want to go for that approach I'll reenable the Add Wiki page button. I'm all about figuring out what works as opposed to forcing users into a specific model until we figure out what works well. Perhaps we should add a pop up on rolling the mouse over "Add Tool" and "Add Wiki Page" explaining what each might be used for. Listing what pages link to a wiki page on a wiki page would also help.
Ok, I removed the "Add wiki page" link until we find a solid need for it.
Well put!
Try editing and saving that comment again. It should fix the links with the "Markdown Syntax and HTML" Text Format selected. More info over here -> http://dev.farmhack.gotpantheon.com/comment/39#comment-39