ve blogged about. I see [i] a lack of accountability and [ii] a bad end-user experience. Letâ€s talk about the latter. For someone who does not manage to make the cut with the request - how can we ensure that we provide alternative paths to the media ? Because the primary reason for raising the ticket was to obtain the media. The corollary here is that the ease of raising a ticket increases the chance of freeloading. So, I see an important question here - do we work towards decreasing freeloading or, do we work towards strengthening the routes to media. And, I do not have a definite answer at this point. In fact, I do not want to have.
Having said all that, [i] is another part that bothers me. Just how do we expect people to contribute to the project by volunteering for Freemedia ? Recent trends in requests for various swag does indicate that we are approaching that margin of freeloading wherefrom there are only two paths - either raise the bar on swag entitlements or, just write off the costs. I am wary of doing the latter. What you mention as being dependent on *UGs, I see as a means to enforce that Ambassadors have their ear to the ground. I see an somewhat unhealthy trend of Ambassadors working in isolation in an elitist silo. That is going to be counter productive. As regards, what can be done - we should actively start looking at and, incubating commercial sponsors/vendors for the media including possibly exploring the possibility of allowing co-branding. Perhaps that would make it worthwhile for people to approach us and charge a sum to sell the media.]]>@susmit – we’ve had long discussions about this. And, my current pet peeve with FreeMedia is what I’ve blogged about. I see [i] a lack of accountability and [ii] a bad end-user experience. Let’s talk about the latter. For someone who does not manage to make the cut with the request – how can we ensure that we provide alternative paths to the media ? Because the primary reason for raising the ticket was to obtain the media. The corollary here is that the ease of raising a ticket increases the chance of freeloading. So, I see an important question here – do we work towards decreasing freeloading or, do we work towards strengthening the routes to media. And, I do not have a definite answer at this point. In fact, I do not want to have.
Having said all that, [i] is another part that bothers me. Just how do we expect people to contribute to the project by volunteering for Freemedia ? Recent trends in requests for various swag does indicate that we are approaching that margin of freeloading wherefrom there are only two paths – either raise the bar on swag entitlements or, just write off the costs. I am wary of doing the latter. What you mention as being dependent on *UGs, I see as a means to enforce that Ambassadors have their ear to the ground. I see an somewhat unhealthy trend of Ambassadors working in isolation in an elitist silo. That is going to be counter productive. As regards, what can be done – we should actively start looking at and, incubating commercial sponsors/vendors for the media including possibly exploring the possibility of allowing co-branding. Perhaps that would make it worthwhile for people to approach us and charge a sum to sell the media.
]]>Collaborating with lugs are a way to scale up availabilities. But should this be the only way?
Can we really afford to say these?
Go to xyz lug(or vendor) and find out if they are willing to provide/sell you a Fedora media. If they say no, we are sorry to say there is nothing we can really do about making fedora available to you!!!
]]>@susmit – if there are volunteers who are lining up to resell, I guess pointing them to the right source for getting them printed would work
]]>The problem with the second one is: How do we distribute it? Also it costs ~3INR for each label. ]]>
The second one is of no concern at all.
Every requester gets an email on every update of his/her ticket. If someone takes up the request, it will be notified to the requester. If someone ships the media and closes the ticket, the requester will be notified. I tried to take care of every possibility. 🙂 Although I have a few areas mentally marked for improvement.
]]>While implementing the system, I could think about two types of duplicate:
Case 1: Multiple request, Email addresses are same, but addresses are not.
Case 2: Multiple request, email addresses are different and addresses is same.
The current system automatically finds out these two types of duplicates, and make them available for closing as duplicates via (trac) report 23 and 24.
We close them before processing a month’s request.
Also, I designed the system such a way that once someone request for a DVD, all the subsequent requests for a particular release (say F10) will be marked duplicate, as per our “One DVD/Person/Release” policy.
]]>