
An interesting video was passed to a friend of a friend who subsequently passed it on to me about the original intent and virtues of copyright in America. Not surprisingly the video outlines the original intent of copyright to encourage the creators to bring new content and protect them for a period of time. As the video points out one of the largest instigators of the new rules on time privilege for creators was the Disn
There is a fair amount of conversation and research into this practice. Most disruptive research points at the classroom of the future being "facilitated" by someone with a liberal or general education background. This would mean in K-12 setting a class room might have 20-30 terminals with students learning from on-line courseware/remote instruction while there is a general practitioner or some facilitator there to answer questions. There is a good book by Horn & Johnson on this topic, I think it is called Disrupting Class. It is a really insightful piece of work - I liked it so much I shared it with our local superintendent of schools.
I think we are already seeing distance education in higher ed heading in this direction. You don't really need to sit in a lecture hall if you can get the same info in a web cast from someone who is an expert in the subject. Cohorts can have virtual meetings and whiteboard over the internet. TAs can be available anywhere. We will see more of this transition, esp. when the education bubble hits us in the next few years. (Young adults who have gone to school b/c no work, fewer students affording education, institutions cutting costs and closing buildings, forced retirement of instructors due to budget cuts, etc.)
There is a nice little interview with Christensen, Horn and Johnson at HBS on this subject too - take a look!. http://hbswk.hbs.edu/item/5978.html
Often times mistakes are made in porting and this one was a big miss. We thought that all the items had been covered in development but there are still some open issues with ops in some of the
Like a lot of light teams we rely on peer review for QC. (If you code it - you don't QC it; a buddy does that work.) We use our internal development team, editorial staff and other members of Geeknet to help in testing. (And sometimes users!) We have been working on a plan to have some automated build testing using hudson or some other automated process to help at least sanity check some key areas of the site on deploy. If you have suggestions on a tool please let me know.
I guess I can only boil it down to: a huge port that had been put off for over 5 years and we broke something - that is to be expected. Not everyone uses the ops in
As a side, in my past experience I have found QC/QA to be one of those things that needs to be approached as a role and not as a person. We are working to foster more of this mindset in our team. QC folks know the product inside and out and (hopefully) don't know the code. (I have found non-programmers to be better at QC.)
We do rely on our community to help us with feedback. If you see something broken, please, raise your hand. Email feedback. Let me know directly (wtapp@geek.net). When we know of an issue it goes on the list and we make decisions from week to week on what the biggest pain points are and then fix those items in addition to other work. Not everything gets addressed - some of it goes to the back burner. Often times we have to hold items because we are in the middle of a sprint. Believe me, our goal is not to reduce functionality of the site, on the contrary we want to make it functional for lots of different users (although there is a significant amount of bloat from 15 years of coding). The team moves from project to project quickly and we try to keep the lid on any issues we do know about including things users like/dislike. For instance, some of our users hate the social media icons - we get it, not everyone wants to play in that environment. Others insist on those interfaces to FB, G+ and Twitter - so we balance and try to make changes and respond so that the site is useful for all.
Please, "directly and openly bitch about" problems. The more we know about issues that the community feels strongly about the more responsive we can be to user needs. Personally I would prefer constructive criticism, if it isn't constructive I can take that too. All I ask is that you make sure I or one of the team see the issue. We don't read every comment, every day and don't want to miss something that is important. In other words, just because you post to the site doesn't mean we know there is an issue. In this instance we happened to know about this by checking Journals.
It is my goal to make sure that you and others understand that we do care about the broad community that comes to Slashdot. The development team is deeply invested in this product and does care about community. I am hoping to be able to pull some project time together for a feedback portion of the site where folks can talk about Slashdot directly and hopefully we can foster more conversation around the site (/woodshed?). We try to do our best to provide a quality site where users can come, read the news, share ideas and thoughts openly and have a little fun too.
You don't have to know how the computer works, just how to work the computer.