Grading Scheme
Louie
probably start hashing out the details now. This thread is to
facilitate this discussion in order to reach a consensus.
Grading Scheme - Possible Benchmarks:
Number of Bugs Fixed
ScreenCast on ISPDB functionality
Documentation - Getting started guide + FAQ
Communication during the project
Public Posts
These are a few of the ideas that were thrown around during the
meeting. If you have any more please feel free to add them.
Things we still need to do:
Decide on Individual vs Group Breakdown
Decide on specific milestones that represent different levels of
achievement
Decide on who grades what - i.e do we assign ourselves a grade or let
Blake judge how successful we are given a set of criteria (If you
don't mind Blake). Remember we need to finish this before the end of
Oct. so please comment!
David Ascher
a) If the ISPDB is live and serving customers by the time you're done w/
the course thanks to your efforts, I will do my best to convince the
Powers That Be that that should be rewarded. I think you probably need
more bugs filed for that to be a realistic goal, but if I were you I'd
argue hard for that -- you'll feel a whole lot of reward if you actually
help make software that's going to help millions of people next year
move forward significantly.
b) From my experience as a student on group projects, if I were you, I
would not want a single grade for everyone. It's too demotivating for
people who are working hard, and too easy for coasters. I'd at least
allow a percentage for individual effort, and a a percentage for group
dynamics/collective effort/coordination.
--da
Louie
as someone once said "A goal without steps to get there is just a
dream". So here are the issues that come up in an attempt to reach
this goal. I'm reading a book about algorithms design and one of the
major things to do each time you finish a loop is to make sure that
you have made some progress. So here are my questions:
1. What is our measure of progress? How do we know when this project
is ready to go "live"? Obviously this is not an easy question because
software can always be improved.I'm guessing most commercial launches
are done at "stable" points in between adding new features. This is
fine.
2. How do we get there? I'm not sure about my team members, but I feel
like I'm only seeing a small part of the big picture. ISPDB is only a
fraction of TB3, so working only on ISPDB makes it difficult to see
the difference between "yak-shaving" and making progress towards the
goal. Currently I rely on the bugs being filed because they are the
only indicator I have as to what needs to be done.
3. What can I do to gain a larger view of the project? How can I step
back far enough to see how ISPDB will fit into the big picture? Can I
run TB3 and see how it might interact with ISPDB? Should I start
reading the TB3 mailing lists?
Not sure if any of these questions can be answered but any advice
would help. I really would like to get it done but I'm having
difficulties seeing what needs doing.
David Ascher
> I think working towards this goal is an absolutely fantastic idea, but
> as someone once said "A goal without steps to get there is just a
> dream". So here are the issues that come up in an attempt to reach
> this goal. I'm reading a book about algorithms design and one of the
> major things to do each time you finish a loop is to make sure that
> you have made some progress. So here are my questions:
>
> 1. What is our measure of progress? How do we know when this project
> is ready to go "live"? Obviously this is not an easy question because
> software can always be improved.I'm guessing most commercial launches
> are done at "stable" points in between adding new features. This is
> fine.
>
Right, we're here talking about putting up a web site which a lot of
people would then submit data to. So, things that are forefront in my mind:
a) some confidence that the webapp works as designed (test coverage)
b) some confidence that the data can be migrated to a new schema when we
decide the data model was wrong.
c) no bad links, words that make sense, etc.
> 2. How do we get there? I'm not sure about my team members, but I feel
> like I'm only seeing a small part of the big picture. ISPDB is only a
> fraction of TB3, so working only on ISPDB makes it difficult to see
> the difference between "yak-shaving" and making progress towards the
> goal. Currently I rely on the bugs being filed because they are the
> only indicator I have as to what needs to be done.
>
Yeah, I get you. However, you can think of ISPDB as a completely
standalone project, of which TB3 is just the first customer. Is it a
website that you could tell your geekier friends at school that they
should use so that other students at the same school can get Thunderbird
configured seamlessly?
> 3. What can I do to gain a larger view of the project? How can I step
> back far enough to see how ISPDB will fit into the big picture? Can I
> run TB3 and see how it might interact with ISPDB? Should I start
> reading the TB3 mailing lists?
>
Download TB3 nightlies
(http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/),
and create a new account -- that first dialog that asks for your name &
passwords talks to the currently static version of the ISPDB. What
we're talking about is a way to let people populate that web service
with thousands more configurations. Helps?
> Not sure if any of these questions can be answered but any advice
> would help. I really would like to get it done but I'm having
> difficulties seeing what needs doing.
>
>
hopefully this helps.
traveling for the next 9 days, but will try to answer emails.
--david
Eric Henry
- Every aspect of the ISPDB software should have tests written for it
- Any bugs that would block TB3 should be resolved
- We will have a screencast of the ISPDB software
Eric
Louie
been mentioned and throw some preliminary numbers on because we need
to get things moving.
Communication
On Blog
On Mailing List
During Status Meetings
Deliverables
Screen Cast
On Oct 25, 9:18 am, Eric Henry <ehen...@gmail.com> wrote:
> So what I am hearing is that by the end of the semester we should accomplish
> the following:
>
> 2. Any bugs that would block TB3 should be resolved
> 3. We will have a screencast of the ISPDB software
> So, if this is true, it seems like all we need to do is divide up the work
> amongst ourselves and create a plan on how we are going to accomplish our
> parts....?
>
> Eric
>
> On Thu, Oct 22, 2009 at 6:51 PM, David Ascher
Louie
been mentioned and throw some preliminary numbers on because we need
to get things moving.
Communication
On Blog
On Mailing List
During Status Meetings
Deliverables
Screen Cast
On Oct 25, 9:18 am, Eric Henry <ehen...@gmail.com> wrote:
> the following:
>
> 2. Any bugs that would block TB3 should be resolved
> 3. We will have a screencast of the ISPDB software
> So, if this is true, it seems like all we need to do is divide up the work
> amongst ourselves and create a plan on how we are going to accomplish our
> parts....?
>
> Eric
>
> On Thu, Oct 22, 2009 at 6:51 PM, David Ascher
Louie
Since no one is replying, I'm going to at least summarize what has
been mentioned and throw some preliminary numbers on because we need
to get things moving.
On Mailing List
During Status Meetings
# Bugs Fixed
Test Coverage
Did we achieve our goal (ISPDB is capable of soliciting
configurations from users + verification can be done by authenticated
persons)
Screen Cast - 10%
I think the 70% of deliverables can be broken down into team/
individual marks. Screen Cast should be a team effort and
Communications purely individual.
Suggestions on Team/Individual breakdown of Deliverables?
I'm suggesting a 35/35 breakdown.
Post comments! This isn't just going to be for me.
Lindauson
schemes. So far most of my progress is almost directly analogous to
Greg's "Yak Shaving" analogy.
I should say though that I do agree, in most-part, with your
suggestions. I strongly agree with the following considerations for
grading:
Communication
Bugs Fixed/Tested
Documentation
Lin
jsch...@gmail.com
Though I don't know about simply having # of bugs fixed, because that
tends to promote only working on bugs that are quick and easy to fix.
Louie
needs to chime in about the amount of work other people have done. I'm
hesitant to suggest this because it's difficult to see how involved a
bug can get unless you are actually working on it yourself. Like all
problems in grading, easy metrics are never fair reflections of the
underlying task.
Also to be settled: Are we going to do our own evaluations, do we want
blake to do it (since he's reviewed all our patches), or perhaps David
A. to say "well, the student team has taken ISPDB from 50% complete
to 75% complete", as an overall measure?
On Oct 28, 12:30 pm, "jschmi...@gmail.com" <jschmi...@gmail.com>
wrote:
Louie
to Greg before Friday is over. I won't have time because I'm at work.
On Oct 29, 12:18 pm, Eric Henry <ehen...@gmail.com> wrote:
> I think team evaluations only work well if you are working really closely
> together on something. Like you said, we don't really know how much effort
> everyone is putting in on everything.
>
> Also, I posted the grading scheme on the
> .
>
> Eric