Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

ColinD

Owner
  • Content Count

    4,317
  • Joined

  • Days Won

    37

ColinD last won the day on April 15

ColinD had the most liked content!

Community Reputation

76 Excellent

About ColinD

  • Rank
    Elder God of Policydb8
  • Birthday 05/25/1994

Personal Information

  • Name
    Colin Dailey
  • High School
    Smithville/Kingwood
  • College
    GMU
  • Occupation
    Policydb8 Owner/Coach at GMU

Recent Profile Visitors

2,217 profile views
  1. 2019 in debate is a far cry from what it used to be. Goodbye paper, expandos, and tubs. Goodbye photocopying and printing. Goodbye asking to look at a physical card to write down the citation. We exist digitally in word documents, virtual tubs, caselists with full speech documents, and repositories like the Open Evidence Project. Evidence has, in many respects, gone from a hoarded commodity to being a community resource. The ironic thing is, as we create more evidence solutions, we create new problems in how it works: poring through files to find a single card; spending an inordinate amount of time formatting files, structuring them, perfectly naming and organizing headers. Printing a single debater’s dropbox now would likely collapse a handcart. Evidence has become more readily available to all, but as the amount of accessible evidence has exponentially increased, the management and organization of this evidence has become a gigantic task. Arvind Balaji, a 16 year old Junior at Round Rock High School, may have the solution. Arvind is the mind behind debate.cards, an open source, flexible, and free to use evidence search engine. I reached out to Arvind over email to talk debate.cards with him to see where it came from, how it works, and where it can go. [Our emails have been lightly edited for readability in an article format. No content has been censored or changed in meaning.] ------------------------------------------------------------------------------------ Colin: How long have you been involved in debate? How did you get involved? Arvind: Third year debating. I knew a few friends that debated in high school, figure I would a give it a shot.. and here I am three years later haha Colin: Where did you get your interest in coding and when did you start? Arvind: I've had interest in computers since I was young, my parents are both software engineers which is suppose helped me to foster that interest. I kinda just taught my way to code along the way, from starting out with simple website and working up to full fledged projects like debate.cards Colin: Wow, so you have a pretty deep history with software development. I saw on your github (snooping) that you have developed a debatetimer and an openevidence download tool among other things. Have you done any large projects as sophisticated as debate.cards? Arvind: I think debate.cards is definitely the most ambitious project I've taken on so far, but the smaller projects along the way helped me learn a lot. Colin: Is [software development] what you intend to pursue after you're done with school/is this partly an exercise in building your portfolio? Arvind: I haven't completely decided yet, but I think I'll most likely be pursuing CS. And yeah, I definitely think debate.cards is a good contribution to my personal portfolio. Colin: What programming languages are you most familiar with? Arvind: I'm fairly comfortable with Java, Python, and Javascript. Recently, I've found my self working Javascript/Node the most. Colin: A lot of people draw parallels between debate and other activities (usually something they personally find interesting. Do you see a relationship between coding and debate? Arvind: For me personally, coding and debate are both things that I'm passionate about, so being able to work on a project that combined the best of both worlds is something that incredibly fun and rewarding. Colin: There are some examples of individuals attempting to monetize software solutions in debate. Why open source and not keep it private? Arvind: debate.cards was created with intention of keeping it free. The goal of debate.cards has always been to make evidence more accessible, I feel that monetizing it ultimately detracts from that purpose. Colin: That's an admirable attitude. Developing something that can be used as a public good should have low or no barriers to access it. Debate thrives on individuals willing to do selfless work for the benefit of others. I have a couple of follow up questions here: Why do you think that accessible evidence is necessary? Arvind: I think that more accessible evidence is a good way to help close the resource gap between small and large school debaters. I also think it just increases the overall quality of debate, having access to more specific and well-research evidence allows for debates to be more educational and in-depth. Colin: There are plenty of people in debate who have disliked some technological changes in how debate works, whether it's the use of laptops or paper, use of internet in debate (more in a regional high school context), using cites or docs, or even using the caselist at all. Most commonly there's a fear that debaters will become lazy and retreat from having to learn independent research skills. An example from [my coaching experience] is that we usually have to go through a period of forcing novice or JV debaters to stop relying on the search feature in their virtual tubs so they actually have to learn their files. You're offering a paradigmatic shift in how people can access evidence in various places online. What effect do you think debate.cards will have in this regard? Do you think this is unfounded or do you just think the benefits outweigh? Arvind: I think that criticism of tech in debate is inevitable. I'm sure the same was said for paperless, open evidence, and open source. While yes, there is a risk that software like debate.cards will lead to lazy debate practices, I don't think it's as big of deal as it's made out to be. I don't think it's an issue that's intrinsic to debate.cards and yes, the aforementioned benefits are probably more important. Colin: In simple terms, how does it work (both front and back end)? What makes it easy to use? Where might it have some user interface challenges? Arvind: At its core debate.cards is pretty simple. First, Word documents are fed into a parser, the parser splits up the individual cards in the document and does a little bit of guess work to get information such as the author and date out of the card. All of the parsed data is then indexed, the indexer allows for quick and powerful searches of all the stored data. Think google, but for debateevidence. The then the last part is the actual user interface that allows for searching through the data, and downloading it back into a word doc. I think the super simple interface it what makes it appealing for users. Search for what you want, then download it. No frills. Ironically, I think this is the cause of its biggest shortcoming. The site currently lacks features that would allow for more advanced searches and better evidence discovery, features that would make it an even more useful tool for debaters. Colin: I noticed that the search bar says "Search for a cite or tag..." So the keywords search are for just those 2 parts? When evidence is parsed through, are cites and tags lumped together for keyword searches or separately? Arvind: I guess that isn't completely true anymore, it searches through the cite and tag along with the heading levels. All three of those things are indexed separately but there isn't currently a way for the user to pick which fields to search in. That functionality will be added in the relatively near future though. Colin: How extensive is its library? What kinds of places can it search? How easy would it be for people to configure their own to crawl other places? Arvind: Currently debate.cards pulls data from the past 7 years of the Open Evidence Project and open source documents from this year's High School Policy wiki. Short term plans include adding the LD and College wiki, but my eventual goal is to open it up for users to directly contribute files. There is currently a section on the GitHub readme file on setting up your own instance of debate.cards which would allow people to add in their own custom data sources, which might be an interesting challenge for those that are tech savvy. Colin: What could custom data sources be? Locally hosted for an enhanced vtub search tool? Or does it have to be web-based? Arvind: It could in theory be anything, the application is written in a way that is modular. So people could in theory write their own modules that would add in new data sources. But to be clear, this definitely isn't something I'm recommending to the average debater or team, or even officially supporting it - it's just an idea. Maybe in the future I can look into adding a more user friendly way to do this. Colin: At the college level there has been some discussion of consent to data collection, even for willingly provided open source documents for disclosure purposes. How feasible is it for you to exclude specific caselist pages from debate.cards? Just as relevant, are you willing to take requests to do so? Arvind: This is definitely something I've been thinking about recently. When I initially added open source docs to the wiki, I took the liberty to assume that those that are willing to open source their documents would also be willing to let their documents be used for something like debate.cards - both of which share the same goal of making research more accessible to debaters. However some of the backlash over oodebate has made me question that. I still think that for the most part that is a fair assumption, especially since debate.cards is not a commercial product. However, I think it's definitely important to respect the feelings of the debaters that put these files out in the first place. There is some technical work that needs to be done first, but once that's ready I'll definitely add an opt out option. Colin: Debate.cards has a lot of potential as it is. What kind of development do you see in the future of debate.cards? Is there an end goal vision of what you think it could be? Arvind: I think the coolest part about debate.cards is the fact that, for the first time, there is a structured way to store and retrieve debate evidence. Instead of being confined to folders full of shoddily formatted word docs, having a more structured and semantic way to store individual debate cardshas enormous potential for the future of technology in debate. I'm frankly not sure what the direction of debate.cards itself will be in the future, but I'm confident that the technology behind it will end up being useful for a lot more than just debate.cards A public API for debate.cards is in the works which would allow other developers to use the data from debate.cards in their own applications and projects. Colin: So do you think that the traditional hierarchical structure of debate files should be dropped in favor of individual card searches? Or am I reading too much into that? Arvind: No not really. I just think that technology in debate is inevitably going to progress, and word docs are just not a very convenient format to work with it. Being able to represent the contents of a speech doc in semantic way just makes developing technology for debate much easier. Colin: What kind of data could be called through the API? Arvind: All of the features of debate.cards (searching, retrieving a specific card, downloading as a word doc) will definitely be available. Beyond that, I'm not completely sure yet. I think that once I get the first version of the API running, I can probably expand the feature set based on community demand. Colin: A lot of nerds in debate at the college level are highly interested in data. Are data analytics and/or visualization somewhere on your checklist? Arvind: Creating analytics is not something I currently have plans for, but the data for others to do so is something that can probably make available through the API. Colin: Alright, last question for you. You've done this by yourself so far, do you want people to help out? How can they do so? Arvind: Yeah help is always appreciated, that's part of the reason why debate.cards is open source. For those that feel like they might have the ability to help out but don't know where to start, just shoot me an email and we can talk. Even if you don't have technical skills to directly contribute, things as simple as making bug reports when you find and issue or providing feature suggestions help out a lot. -------------------------------------------------------- If you are interested in learning more or helping contribute, you can visit debate.cards or find the source code on Arvind’s Github here.
  2. 2019 in debate is a far cry from what it used to be. Goodbye paper, expandos, and tubs. Goodbye photocopying and printing. Goodbye asking to look at a physical card to write down the citation. We exist digitally in word documents, virtual tubs, caselists with full speech documents, and repositories like the Open Evidence Project. Evidence has, in many respects, gone from a hoarded commodity to being a community resource. The ironic thing is, as we create more evidence solutions, we create new problems in how it works: poring through files to find a single card; spending an inordinate amount of time formatting files, structuring them, perfectly naming and organizing headers. Printing a single debater’s dropbox now would likely collapse a handcart. Evidence has become more readily available to all, but as the amount of accessible evidence has exponentially increased, the management and organization of this evidence has become a gigantic task. Arvind Balaji, a 16 year old Junior at Round Rock High School, may have the solution. Arvind is the mind behind debate.cards, an open source, flexible, and free to use evidence search engine. I reached out to Arvind over email to talk debate.cards with him to see where it came from, how it works, and where it can go. [Our emails have been lightly edited for readability in an article format. No content has been censored or changed in meaning.] ------------------------------------------------------------------------------------ Colin: How long have you been involved in debate? How did you get involved? Arvind: Third year debating. I knew a few friends that debated in high school, figure I would a give it a shot.. and here I am three years later haha Colin: Where did you get your interest in coding and when did you start? Arvind: I've had interest in computers since I was young, my parents are both software engineers which is suppose helped me to foster that interest. I kinda just taught my way to code along the way, from starting out with simple website and working up to full fledged projects like debate.cards Colin: Wow, so you have a pretty deep history with software development. I saw on your github (snooping) that you have developed a debatetimer and an openevidence download tool among other things. Have you done any large projects as sophisticated as debate.cards? Arvind: I think debate.cards is definitely the most ambitious project I've taken on so far, but the smaller projects along the way helped me learn a lot. Colin: Is [software development] what you intend to pursue after you're done with school/is this partly an exercise in building your portfolio? Arvind: I haven't completely decided yet, but I think I'll most likely be pursuing CS. And yeah, I definitely think debate.cards is a good contribution to my personal portfolio. Colin: What programming languages are you most familiar with? Arvind: I'm fairly comfortable with Java, Python, and Javascript. Recently, I've found my self working Javascript/Node the most. Colin: A lot of people draw parallels between debate and other activities (usually something they personally find interesting. Do you see a relationship between coding and debate? Arvind: For me personally, coding and debate are both things that I'm passionate about, so being able to work on a project that combined the best of both worlds is something that incredibly fun and rewarding. Colin: There are some examples of individuals attempting to monetize software solutions in debate. Why open source and not keep it private? Arvind: debate.cards was created with intention of keeping it free. The goal of debate.cards has always been to make evidence more accessible, I feel that monetizing it ultimately detracts from that purpose. Colin: That's an admirable attitude. Developing something that can be used as a public good should have low or no barriers to access it. Debate thrives on individuals willing to do selfless work for the benefit of others. I have a couple of follow up questions here: Why do you think that accessible evidence is necessary? Arvind: I think that more accessible evidence is a good way to help close the resource gap between small and large school debaters. I also think it just increases the overall quality of debate, having access to more specific and well-research evidence allows for debates to be more educational and in-depth. Colin: There are plenty of people in debate who have disliked some technological changes in how debate works, whether it's the use of laptops or paper, use of internet in debate (more in a regional high school context), using cites or docs, or even using the caselist at all. Most commonly there's a fear that debaters will become lazy and retreat from having to learn independent research skills. An example from [my coaching experience] is that we usually have to go through a period of forcing novice or JV debaters to stop relying on the search feature in their virtual tubs so they actually have to learn their files. You're offering a paradigmatic shift in how people can access evidence in various places online. What effect do you think debate.cards will have in this regard? Do you think this is unfounded or do you just think the benefits outweigh? Arvind: I think that criticism of tech in debate is inevitable. I'm sure the same was said for paperless, open evidence, and open source. While yes, there is a risk that software like debate.cards will lead to lazy debate practices, I don't think it's as big of deal as it's made out to be. I don't think it's an issue that's intrinsic to debate.cards and yes, the aforementioned benefits are probably more important. Colin: In simple terms, how does it work (both front and back end)? What makes it easy to use? Where might it have some user interface challenges? Arvind: At its core debate.cards is pretty simple. First, Word documents are fed into a parser, the parser splits up the individual cards in the document and does a little bit of guess work to get information such as the author and date out of the card. All of the parsed data is then indexed, the indexer allows for quick and powerful searches of all the stored data. Think google, but for debateevidence. The then the last part is the actual user interface that allows for searching through the data, and downloading it back into a word doc. I think the super simple interface it what makes it appealing for users. Search for what you want, then download it. No frills. Ironically, I think this is the cause of its biggest shortcoming. The site currently lacks features that would allow for more advanced searches and better evidence discovery, features that would make it an even more useful tool for debaters. Colin: I noticed that the search bar says "Search for a cite or tag..." So the keywords search are for just those 2 parts? When evidence is parsed through, are cites and tags lumped together for keyword searches or separately? Arvind: I guess that isn't completely true anymore, it searches through the cite and tag along with the heading levels. All three of those things are indexed separately but there isn't currently a way for the user to pick which fields to search in. That functionality will be added in the relatively near future though. Colin: How extensive is its library? What kinds of places can it search? How easy would it be for people to configure their own to crawl other places? Arvind: Currently debate.cards pulls data from the past 7 years of the Open Evidence Project and open source documents from this year's High School Policy wiki. Short term plans include adding the LD and College wiki, but my eventual goal is to open it up for users to directly contribute files. There is currently a section on the GitHub readme file on setting up your own instance of debate.cards which would allow people to add in their own custom data sources, which might be an interesting challenge for those that are tech savvy. Colin: What could custom data sources be? Locally hosted for an enhanced vtub search tool? Or does it have to be web-based? Arvind: It could in theory be anything, the application is written in a way that is modular. So people could in theory write their own modules that would add in new data sources. But to be clear, this definitely isn't something I'm recommending to the average debater or team, or even officially supporting it - it's just an idea. Maybe in the future I can look into adding a more user friendly way to do this. Colin: At the college level there has been some discussion of consent to data collection, even for willingly provided open source documents for disclosure purposes. How feasible is it for you to exclude specific caselist pages from debate.cards? Just as relevant, are you willing to take requests to do so? Arvind: This is definitely something I've been thinking about recently. When I initially added open source docs to the wiki, I took the liberty to assume that those that are willing to open source their documents would also be willing to let their documents be used for something like debate.cards - both of which share the same goal of making research more accessible to debaters. However some of the backlash over oodebate has made me question that. I still think that for the most part that is a fair assumption, especially since debate.cards is not a commercial product. However, I think it's definitely important to respect the feelings of the debaters that put these files out in the first place. There is some technical work that needs to be done first, but once that's ready I'll definitely add an opt out option. Colin: Debate.cards has a lot of potential as it is. What kind of development do you see in the future of debate.cards? Is there an end goal vision of what you think it could be? Arvind: I think the coolest part about debate.cards is the fact that, for the first time, there is a structured way to store and retrieve debate evidence. Instead of being confined to folders full of shoddily formatted word docs, having a more structured and semantic way to store individual debate cardshas enormous potential for the future of technology in debate. I'm frankly not sure what the direction of debate.cards itself will be in the future, but I'm confident that the technology behind it will end up being useful for a lot more than just debate.cards A public API for debate.cards is in the works which would allow other developers to use the data from debate.cards in their own applications and projects. Colin: So do you think that the traditional hierarchical structure of debate files should be dropped in favor of individual card searches? Or am I reading too much into that? Arvind: No not really. I just think that technology in debate is inevitably going to progress, and word docs are just not a very convenient format to work with it. Being able to represent the contents of a speech doc in semantic way just makes developing technology for debate much easier. Colin: What kind of data could be called through the API? Arvind: All of the features of debate.cards (searching, retrieving a specific card, downloading as a word doc) will definitely be available. Beyond that, I'm not completely sure yet. I think that once I get the first version of the API running, I can probably expand the feature set based on community demand. Colin: A lot of nerds in debate at the college level are highly interested in data. Are data analytics and/or visualization somewhere on your checklist? Arvind: Creating analytics is not something I currently have plans for, but the data for others to do so is something that can probably make available through the API. Colin: Alright, last question for you. You've done this by yourself so far, do you want people to help out? How can they do so? Arvind: Yeah help is always appreciated, that's part of the reason why debate.cards is open source. For those that feel like they might have the ability to help out but don't know where to start, just shoot me an email and we can talk. Even if you don't have technical skills to directly contribute, things as simple as making bug reports when you find and issue or providing feature suggestions help out a lot. -------------------------------------------------------- If you are interested in learning more or helping contribute, you can visit debate.cards or find the source code on Arvind’s Github here. View full article
  3. zizek v peterson debate.mp4
  4. An adaptation of Scrum for agile project management in Debate. Regular file production is something of a lacking function in many high school debate teams, notably for schools that primarily operate as clubs with no established coach on staff. Much of the time, their work relies far more on using openevidence, the caselist, whatever other files happen to come their way, and then far down the priority list is doing work themselves. This results in pre/post season work being unfocused, unorganized, inefficiently done, or non-existent while waiting to see what camps/file selling sites (oops)/caselists put out in terms of files. This problem can exist for a variety of reasons: lack of research ability, card cutting ability, or general confusion when considering how to approach a topic. But, assuming that a high school team has individuals capable of these things, what is lacking? Why is it difficult to have regular original file production? A laisse-faire approach to work ends up being the norm, with debaters all working on their own side projects with little interaction over what they are working on with others (minus the always existing gushing over cool arguments that they found). When that is the case, no matter the size of the team, there will be sizable gaps in the virtual tubs or at minimum, a lack of originality in work. What should occur is team organization: how to identify assignments, distributing them, how to work on them, etc. My goal is to outline a model of team organization built on Scrum, an agile project management framework. While it may seem inconsequential, project management structure has increasing value for debate with the expansion of topic size, information available, and subsequently the number of arguments that exist. For many teams who already have a central process for assignments and file work, this will likely feel familiar. So, a brief introduction to Scrum. Scrum is an agile project management framework, typically used for software development. Agile refers to a set of values for completing assignments. A core principle of agile that Scrum is built off of is continuous improvement. Scrum is a more defined process, a heuristic that prizes adapting to changing factors in how the work process goes. This means re-prioritizing and short release cycles to consistently learn, adapt, and improve work. And Scrum intends to take an incremental approach by breaking down projects into smaller work goals. So let’s break down and define the elements of the Scrum framework and then modify the process to be more applicable to a debate team. (Be mindful that there is a wealth of literature surrounding project management models; the aim here is to minimally define concepts as necessary.) Scrum Team Development Team (Assignment Group) – These teams are a) self-organizing (teams themselves decide how to best accomplish work) and b) cross-functional (all members of the team are capable of accomplishing their work without depending on other team members). This does not refer to the squad as a whole (unless you have a small squad). The ideal group size is in the 3-9 range to ensure there isn’t a loss of team interaction on the smaller end or too much complexity at the larger end. Group organization does not necessarily require that every member of an Assignment Group is working on the exact same file. Rather, Assignment Groups will all be assigned a set of files (or one large file) that they delegate work on among themselves. An important facet of the Assignment Group dynamic is that while groups may be strategically designed to have varying skill levels to balance out group effectiveness, the debaters in the group should take an egalitarian approach with no outside labels, titles, so on affecting the dynamic of the group and impeding effective collaboration. It does not make for an effective group for a debater to be labeled a novice or JVer who doesn’t know what they’re doing. Product Owner (Assignment Lead) – A better term for debate is the assignment lead and likely is a head coach, team captain, or simply the person who has the best sense of the pulse of the topic. The assignment leader controls the product backlog, or list of assignments for overall work period, and prioritizes importance of assignments. An important feature is that there is one, singular assignment lead purely for the sake of ensuring that there is consistency and lack of contradiction in priorities. This does not mean that there cannot be input from others, but that there is an executive decision made about how to prioritize and hand out assignments to decrease the risk of the ever dangerous “too many cooks in the kitchen.” While in a typical Scrum framework, the Assignment Lead is removed from the actions of Assignment Groups, to better fit the typical format of a debate team, they would likely have a second role as a Group Lead. Scrum Master (Group Lead) – A better debate term is group lead, but that is still a slightly misleading term. This is either a more senior debater or a coach. The point of this role is not a hierarchical authority that working groups are answerable to. Instead, the goal of the group lead is to coach the assignment group to be self-organizing, coach individual team members in cross-functionality (referring to completing their assignment from research to formatting to quality to file organization to file submission), and removing impediments to progress (ie helping identify and filling file gaps, assisting in overcome research blocks, etc). Outside of working with the Assignment Group, Group Leads should coordinate with the Assignment Lead and other Group Leads to discuss organization, planning implementation of Scrum and when it should occur, and how to improve efficiency. Scrum Events - Sprint (Wave) – A sprint is a time period of a month or less in which a “Done” and usable “Increment” is created. These time periods should be consistent during a development effort and a new sprint starts immediately afterward. Some key rules for a sprint are: no changes are made that would veer from the sprint goal, quality goals do not decrease, and the scope can be clarified or re-negotiated between the assignment leader and the development team as new issues arise. Each sprint has a goal of what to accomplish, and a flexible plan to meet that goal, and a finished increment at the end. Sprint Planning – Self-explanatory name. The key questions are what can be achieved in the sprint and how will the work to complete a file be achieved. Work is selected from the assignment list (product backlog) and put into the sprint assignment list (sprint backlog). This is a collaborative session for the Assignment Group; the Group Lead should take a monitoring and assisting role, not leading it. This is a time period that Daily Scrum – This is a daily, roughly 15 minute box of time for the development team to synchronize work and plan for the upcoming day. This time is used to examine progress toward the sprint goal and completing work in the assignment list. An important distinction to make is that this is not a status meeting. This is not a time where debaters report their work to a coach or lead on their assignment and then are told what they should do different. This is a self-organizing exercise where debaters discuss and collaborate in their working groups to measure group progress toward achieving their sprint goal, identify issues, adapt as necessary, and set daily goals together. It should happen at a consistent time and have full participation. It is important that this happens at a single time is to ensure group participation and effective group evaluation of progress. A series of facebook or slack messages from varying group members throughout the day is not productive because that simply devolves into giving status updates. The group leader should supervise, but only for the sake of ensuring that the working group is staying on task and keeping to the point. Sprint Review – This is held at the end of the sprint to inspect file work done and adapt the assignment list if needed. This includes the development team, the group lead, the assignment lead, and all other relevant parties. The goal is for the assignment group to demonstrate work that is “Done,” for the assignment lead to determine what is “Done,” and for the entire group to collaborate on what should be changed about the assignment list and what should be done in the next sprint. Sprint Retrospective – This occurs after the Sprint Review and before the next Sprint Planning session. The goal is for the assignment group to discuss what went well during the Sprint, what could be improved, and what they will commit to improve in the next Sprint. The Group Lead will oversee the meeting in order to ensure that debaters are participating and understand the purpose of the meeting. By the end, the Assignment Group should commit to making changes to their process to be more effective AND more enjoyable during the next Sprint. Scrum Artifacts Product Backlog (Squad Assignment List) – The product backlog is an ordered list of everything needed in a product. In context of debate, that means an assignment list for everything that will be needed in the tubs. It should be ordered by priority. This does not need to happen all at once, but can be broken up in varying sprints/assignment waves. Sprint Backlog (Sprint Assignment List) – This is the set of product backlog items that are being worked on in a sprint, or assignment wave. An important note is that this is a forecast of goals that the team believes can be accomplished within a sprint. To ensure that improvement goals are being met, it should improve at least one high priority process improvement from the previous retrospective meeting. Increment (Completed Files) – An increment is the sum of all of the backlog items completed during a sprint and the value of increments from previous sprints. The goal of Scrum as a framework is to “deliver” a “Done” increment. The definition of what “Done” means is important. There is no stable definition I can provide outside of a file being usable. The key is that there is a shared understanding from team members of what “Done” means, what makes a file usable, what elements are needed, etc. Application to Debate Now that the model has been generally defined, let’s walk through what the application of this model can look like for a debate team. Early pre-season/Topic announced: Team does a basic mapping of what the topic can entail, different areas for affirmatives, negative files to cut, arguments to anticipate, etc. Debaters and coaches express arguments that they have the most interest in, think will be most relevant, etc. This enables the Assignment Lead with input from others to build the Assignment List, define what these assignments are with a general concept of what they should be upon completion, and appropriately prioritize arguments. Given the structure of teams and balanced outside obligations for debaters, weekly team meetings should be of multipurpose function for Sprint Reviews, modifying the Assignment List, distributing assignments to groups, then groups break off for sprint retrospectives of the previous sprint and Sprint Planning for the current set of assignments. In the Sprint Review, the Assignment Lead will evaluate “Done” files (or have done so before the meeting starts since that can be time consuming), the Assignment Group and Group Lead will make recommendations for what should change about the Squad Assignment List (completed files should be removed, a file isn’t complete and should carry over to the next Sprint, new file ideas were discovered while working on the Sprint, etc.). The Assignment Lead will appropriately modify the Squad Assignment List based upon completed files and recommendations in Sprint Reviews. Individual Assignment groups will have their Sprint Retrospectives. This is an opportunity for debaters to discuss how they could improve their coordination, individual work efforts, adjust the level of work they think they can accomplish (“did we take more than we could complete?”), and carry those changes into the next Sprint. Assignment Groups choose or are given a set of assignments based upon what those groups believe they can handle. This can vary. In the early pre-season, putting together an affirmative master file or a large case neg for a presumed core of the topic aff can require the coordination of an entire assignment group, depending on its size. For smaller assignments such as DAs or CPs, those can be handled by one or two people, depending on capability. The Assignment Lead ensures that the Assignment Groups understand the files that they have been assigned are and what they entail. For building larger or a greater quantity of files per group in the summer, longer sprints (up to a month) can be more useful to ensure that assignments will not HAVE to be carried over to the next sprint. Assignment Groups will plan their sprints. This will involve outlining and mapping out what a completed file should include, functionally creating sub-assignments within the assignment, defining what makes the file “Done,” and then delegating file work among themselves. Even if working on different files, the group should collaborate as a whole to outline files. This is especially important if a group has a large number of smaller assignments given to them, meaning that initially, not all files will have someone working on them and will only be taken up by an individual debater after completing a previous file. This will make file completion a more incremental process that can result in meaningful goal-setting and accomplishments on a daily basis. Given the modular nature of file work being done, debaters in their groups should also delegate who will compile which master files. In Daily Scrums, debaters will talk as a group, set goals for themselves for that upcoming day, discuss what they accomplished or didn’t accomplish of their goals in the previous day, examine how they should adjust their work process or work level they are capable of in the upcoming day, and discuss any modifications that should be made to file outlines based on research that they came across. This is a self-reflexive period in which debaters should aim to be aware of their strengths and weaknesses. Other debaters should aim to offer advice on goal-setting or execution of the different elements of file-building (search terms, databases to look at, what a card should say, formatting, file construction, etc.). Part of the goal is for the Group to assess overall progress of their Sprint Assignment List. Based upon self-assessment and outside assessment from their Group Lead, they should consult with their Group Lead for assistance and how to improve. While doing work during a Sprint, debaters should pay attention in their research/file work for possible future assignments that could be added to the Squad Assignment list, appropriately saving articles/books and taking note to recommend to the Assignment Lead in the Sprint Review. If it is pressing, it should be sent to the Group Lead who will communicate to the Assignment Lead. Simple reason for the hierarchy: on larger squads, this can result in the Assignment Lead being bombarded by constant messages from a dozen or more different debaters on a regular basis. The Group Lead has the responsibility of regularly reviewing work put out by debaters in order to ensure quality, monitor performance of Group members, and ultimately approve of files being done. Depending on the deadline and total progress being made, the Group Lead should cut cards to fill holes of files or assist in research for difficult portions of files. The Assignment Group should have their files “Done” before the end of their sprint or made as much progress as possible. They should have time for their Sprint Review BEFORE the file submission deadline is due. Then we come back to the team meeting and it all starts over again. Additional notes: The Group Leads and Assignment Lead should regularly discuss changes to the model, different group capabilities, file prioritization, etc in coaches meetings or over a chat medium. It makes the most sense to have this meeting not long after overseeing Sprint Retrospectives. Every person on the team is responsible for reporting holes in files, avenues to research, etc. It makes the most sense to do so on a central spreadsheet or through Group Leads so the Assignment Lead does not get bogged down with messages, especially as team size scales up. Organization This model requires a lot of coordination and in turn, organization. Here are some guidelines for what that should look like: The squad writ large should have a messaging medium (team slack, fb messenger, POLICYDB8 CLUB, gchat, etc.). Assignment Groups should each have a messaging medium (slack channel, different fb chat group, DIFFERENT POLICYDB8 CLUB, different gchat group). These communications should include audio/video chat capabilities or an alternative should be used for those functions so various meetings do not have to occur in person. The Squad Assignment List should be on a spreadsheet or some other open, transparent location the team as a whole can see. Ideally only the Assignment Lead can modify it (because people will undoubtedly mess it up and cause confusion at some point.). Highly recommend Google Sheets. Also, of course, POLICYDB8 CLUB (use the forums and edit a post continually). Assignment Groups should have a spreadsheet as well. This is where things get interesting. Assignment groups will have their sprint assignment list. They should have this organize into an interactive visualization of work being done. List items should be categorized into “To Do,” “In Progress,” “Blocked,” “To Verify,” and “Done.” “To Do” should be all of the items that the group wants to complete during a Sprint. “In Progress” is all items currently being worked on (taken by debaters as a daily goal). “Blocked” are items that debaters cannot complete or need help with. It is the responsibility of the Group Lead to help with these items. “To Verify” is for items that debaters believe are done but the Group Lead needs to check. “Done” is for items that have been completed. Only the Group Lead should move items into the “Done” column. This model also means that files should be sorted differently during Sprints. Assignment Groups should have a shared cloud folder (Like Dropbox). Different Assignments should be in different folders (Heg folder vs Aff Case folder), and then should be split into Master Files and Daily Files. Master Files are the final product of a Sprint. While the Sprint is in-progress, the Master File will be organized in an outline format with headers reflecting list items. Daily Files are for the work that are done on a given day by individual debaters. As Daily Files get verified and categorized as “Done,” they should be compiled into the Master File. Team-wide file sharing method doesn’t matter that much. Can be a listserv, dropbox, POLICYDB8 CLUB, Onedrive, etc. Other recommendations for a more tech-minded team would be self-hosted file sharing web applications like ownCloud or NextCloud, both of which have integrations with various chat or project management features that could aid in the execution of this kind of assignment process. So why use this model? This sounds complicated, I know. It takes more thought than just “hey debater, what do you want to work on? Cool, work on that." However there are a variety of benefits. Makes work manageable Overwhelming younger debaters is real and burnout is real. Incrementalization makes tracking progress on file work simple and ensures that work levels are easily changed without the typical "so and so checked out" or "x novice/JVer doesn't get it" appearance. For many who don’t have as much experience, the idea of doing a file by themselves is daunting to the point of not being able to accomplish anything. For many who have other life, school, or work events come up, the idea of taking regular large files sounds like a recipe for stress and disaster. By nature, this structure teaches debaters how to approach file structure, how to manage time, and how to ask for help. Educational for less-skilled debaters Understanding what goes into mapping out a file and how to manage doing file work can be elusive for debaters. By doing this process in a collaborative environment, lower skilled debaters can learn from more experienced debaters how to do so by effect of Sprint Planning sessions. Moreover, Daily Scrums are an opportunity for direct engagement and consultation between debaters and coaches as well for advice and assistance. Ensures file work is transparent and debaters are honest about their limitations There is always an issue of debaters volunteering for more assignments than they are capable of. By reducing file assignments to a variety of small parts that are individually worked on daily, debaters get a better feel for how much time they really can put into debate in a day and how much work they can do. Part of the function of the Daily Scrum is for debaters to be up-front about how much they think they can accomplish that day. This resolves a lot of the “bite off more than they can chew” problem. Moreover, the assignment boards and direct involvement with their group and group lead ensures that progress is shared in an open environment. This means coaches and group members have a solid idea of how files are coming along. It also means that coaches have a better indication of when they should intervene with debaters who have trouble completing their assignments. Creates an environment for consistent work being done Oftentimes assignments are levied on a weekly basis for debaters to finish, leaving it on them to determine how to balance out work on a given file. For more than a few, this results in procrastination and last minute all-nighters, typically resulting in a lackluster file or vague excuses like “uh I ran into walls while researching.” Daily goal setting in Daily Scrums means daily work being done. Allows for flexibility The Scrum model can vary in scale on time, group size, and level of engagement based on a given squad’s needs. Even further on flexibility, the incremental nature of file work along with the open showing of file work done means that any given person in a group or the group lead can pick up where someone left off and finish a file. This may sound unwieldy for effectively operating during the regular season, especially when considering school, classes, and so on interrupting the ability to regularly work or coordinate. Something important to note is that the time period for Sprints can be scaled down as much as necessary (like getting assignments on Tuesday for a tournament starting Friday) and Assignment Groups do not always have to take a massive group of assignments. Clearly people can take a break on days when it’s necessary (need to do schoolwork, need some personal time, the assignment list is small and doesn’t require everyday work) or skip Sprints when necessary (midterms week, finals week, family vacation, etc.). The advantageous thing about the Scrum model is that it is flexible by design, capable of many different degrees of intensity. Lastly, this is a valuable resume material Learning project management and having experience in it (particularly a popular method like Scrum) is a valuable skill that is marketable. While debate has a variety of different portable skills that can be pointed to (public speaking, critical thinking, research, etc etc), a lot of those can sound vague to an employer. Being able to say “I have x number of years of experience in Scrum project management as a development team member/scrum master/product owner” is much more tangible and is an attractive resume item. Find this interesting? Discuss it in the comments or the forums. The best thing about a model like this is that it is and should be adaptable. Most importantly, it is something I want to get feedback on and discuss. Want to go even further? Policydb8 will be doing a free summer workshop for high school debaters that will use this model to produce files as well as give lectures to equip them with the necessary tools to avoid camps. If you're interested in participating (even if you are not a high school student), stay tuned to our email list and/or social media pages for further details.
  5. 2004 NDT Documentary.mp4
  6. Call me biased, but I'm torn between GMU AH and GMU BT.
  7. Worth talking to the director of forensics about it. I'm sure many people in the college policy community would be interested in offering support, including us (Policydb8 owners).
  8. Designed with debate in mind. It's cool that it is so intuitive to use.
  9. In the wake of NDT second round bid announcements, there has been some controversy over the second round process, particularly regarding third teams from schools that applied (who are separately pooled off from first and second team applicants and then evaluated). Hopefully a dialogue can start on why the current process is best or alternatives that should be considered.
  10. Switched to parli. Or that's just what they have now. Before my time tbh.
  11. Sure I'll let you get away with that.
  12. Literally the first result for on Google for ""CCRU Writings 1997 2003" pdf" https://libcom.org/files/[Ccru,_Nick_Land]_Ccru_Writings_1997-2003(BookZZ.org).pdf
  13. Check out the buy button at the bottom of the book info. Automatically shows where to get it on amazon. (Whaaaaaaat)
  14. Hello all! We have doubled down on our efforts with Policydb8. Here is what is new: - New theme: We have made one universal theme for the site to a) establish a singular universal look for the site and b) get a sleeker appearance focused on user experience and readability. We aim to lock down this look for a long time to come and improve upon it. Our previous themes are still available with caveats: being an owner, being a moderator, or reaching a post count of 250. - Logo contest: With a new theme, we need a new logo to both revamp our look and get our users more involved with the development of the website. This logo contest will come with a $50 prize and the user's name being enshrined permanently on "Our Partners" page. Read more about it here! - Books threadstarter: We have filled a gap in our community by creating a Books and Articles forum. Even better, we have modified it with a "Threadstarter" feature that allows for users starting a thread to search for a book title and have its information (title, synopsis, related books, and where to buy) automatically published in their post. Check it out! View full article
×
×
  • Create New...

Important Information

Terms of Use