Thanks for you're reply. Reaching consensus about the amount of story
points is indeed a challenge. I allways found it difficult to relate
story points related to a number of hours. I see story points more as a
rough estimate.
But I think that once you take a tory, you agree with making that work
within a given period, and for being paid the given hours.
It's entrepeneurs risk if it takes you longer... ;-)
But it would be good as well to schedule availability for our members.
So that we will be able to give an estimate to our customers.
Well, have to hurry now... ;-)
Jarra
> Hi Jarra,
> Thanks for your feedback!
> I think I wasn't entirely clear on the tariff issue, but it was my
> thought exactly as you propose.
> See also http://rubycoop.org/workflow.html where I wrote:
>> Q: How much does the member get paid for its contribution?
>> A: Standard tariff per hour multiplied by the story-points
> Of course that still leaves us with the challenge of reaching a
> consensus in estimating the amount of story-points for a scenario /
> user-story. Although this will be a decision of the members of the
> core-team of a particular assignment.
> I have no idea for a definition of a so called qualified Ruby
> developer. And if we follow the payment per scenario it may be not
> that important, although we need to have (or strive for) coding
> standards. If I submit a patch to what kind of open source project,
> there is no-one determining if I'm qualified to submit my
> contribution. The main criteria is the quality of the code (at that
> moment for that patch). But the question is maybe about a membership
> of the co-op. Can 'anybody' be a member of the co-op and who decides?
> I think that if we have enough critical mass in the number of members
> with which the co-op starts, it will sort it self out ......
> And one benefit of the co-op is that you can participate part-time.
> Someone's involvement can be on (only one) user-story basis.
> Best,
> Frank
> On May 25, 11:02 pm, jarra <the.voyage.and.the.messen...@gmail.com>
> wrote:
>> Hi Frank and others,
>> I very much like the idea of a "Ruby cooperation". I had a fulltime Ruby
>> on Rails job for 2.5 years. Currently I am freelancing and my main
>> freelance job right now is as a process and issue manager for the
>> implementation of an open source CMS, so right now I'm not doing a lot
>> of Ruby and Rails (I miss it ;-)), but it's my platform of choice.
>> Although I think the hourly tariff is good, I'm not sure about the idea
>> of working for an hourly tariff. Some programmers are quicker than
>> others, and everyone has his/her own skills.
>> So I'm playing with the idea of splitting a project in different user
>> stories, and writing them down in Cucumber scenarios. Each scenario has
>> an some story points, with a certain value (estimated hours * hourly rate).
>> Programmers can pick the stories that suit them best and fit to their
>> skills, and less experienced and slower programmers using more hours for
>> a lower hourly rate and quicker experienced programmers taking less
>> hours for a higher rate earn a similar amount for a given scenario. Does
>> this make sense?
>> And what about skills. It would be good to have people with different
>> skills. My prototype skills are pretty good, but I'm less skilled in CSS.
>> And what is a "qualified" Ruby programmer. I have 2.5 years of fulltime
>> Ruby programming experience but I have no certifications or whatsoever.
>> Are there any?
>> Maybe it would be better to have proper coding standards (no more than 6
>> lines of code within a function), and use Cucumber and a unit testing
>> suite (Rspec ;-))
>> Currently I am not fulltime available. I have a freelance job that takes
>> 16 to 24 hours a week at this moment, but might end within a few months.
>> Will it be possible to work less then 40 hours a week? Will it be
>> possible to have an availabilty that varies?
>> I agree with using Github and Pivotal. But iChat doesn't work on
>> Linux... ;-/
>> Jarra
