user stories of supporting paying to any packages in npm #964
Comments
|
@nobodxbodon Nice! Can you add this to the |
|
After re-reading the feedback from a potential giver, IMO we should follow his suggestion as early as possible, as a mini market researching that takes almost zero effort, comparing with the 3/4-month hacking ahead if we decide to pursue the idea. Even though we don't have the npm integrated yet, we may get more receivers signed up and a second company giver, which will mean a lot to the npm integration project (more and earlier direct feedback, etc)
|
|
@nobodxbodon GitHub projects is a little confusing—can you use the "+ Add cards" button at top right to link this ticket, rather than creating a "Note"?
|
|
@whit537 done. Adding one more item: giver gets reports about how much of their giving is claimed by which team, and how much is not. I'll create a separate issue to track #964 (comment). |
|
@nobodxbodon Awesome! How about also reaching out to companies to potentially give? Here's one I found because they liked our tweet about the GitHub ribbon. |
|
@whit537 that may belong to a larger marketing campaign. Maybe include all the company likers on Twitter or followers, and also include contacts in other social accounts perhaps. Still IMO #969 has higher priority, as we'd better get direct feedback from the other part of user groups ASAP (AFAIK we don't have any formal ones yet?). |
We have 285 formal ones, don't we? ;-)
|
|
Do we know if any are on npm? Besides, it can mean different to have another company giving to the team owner (IIRC there was one team owner refusing giving as it has conflicts with his contract). Besides there is devil in the details, which needs to be addressed anyways and IMO sooner than later. Also, we will need to draft up messages to reach out to project owners to notify about the pledges, and the same message used in the research can be reused (the communication part is one critical part of the project). Ideally we should get some rough estimates about market, like how many active project/owners will be interested after npm integration, etc. I won't insist on a market research like this if the whole project can be launched in a month, but if we need to spend 3-4 months of work and marketing, I don't see the reason not to better understand the market as early as possible, as we won't have much extra time to make strategic mistakes. Speaking of which, maybe it's time to draft up a possible timeline for this and see if it can be accomplished incrementally, instead of an 'all-in' in the end. |
|
Some two year old stats about npm: I guess the percentage of orphan packages can only be higher now. As companies won't give to those, our pertentage of target projects is between 1% ~ 25%. Assuming those 1% packages are popular enough, let's go with 1% as a worst case, and npm now has 400k projects. That's 4k projects. Assuming half ot them are company projects already, we have 2k projects. 25% gets us 100k projects, but we'll need to take other factors into account, like non-active project, single developer's project (only A dep on B dep on C, but all from the same developer), etc. |
This is true, but as discussed with relation to Chocolatey, helping standardize funding avenues cold be an attraction for maintainers, especially for those projects that are actually being used. |
I agree. The estimation above is only based on the current state of the packages. Surely the "orphan packages" can get more active and influence if they realize our impact, but those are indirect and even harder to estimate. I do believe in the potential impact about this project, but just want to do some basic research, to double convince myself mainly and also set some reasonable expectation of short-term goal. I still consider #969 necessary to get the other part of the story, as it not only can get the estimation above more accurate, but more importantly is a trial run before we put significant efforts into implementation. This trial run IMO is critical to check if our user stories make sense. |
I'm hoping to get to this once Relax Open Work is landed—today!? |
That will be great! Looking forward. |
|
Dependency chain like here makes me concern about the scope. Hopefully we can find a minimum set of user stories for stage 1, to keep workload in controllable manner, as apparently there will be technical debts to pay along the way. |
|
Based on potential company giver's feedback in #969 (comment), it's likely that both givers and receivers can be financially challenged in the first place. Though the companies who are willing to pay will get indirectly benefits by supporting OS projects, I wonder if Gratipay could provide some other incentives to encourage companies by helping boost their growing. That will in turn lead to better sustainability on the givers side. One simple feature for example, if I can see which other companies are also giving to the same project I'm giving to, at least that may provide chance to network. |
|
@whit537 below is an attempt of drafting a very rough timeline: Jan 28, get user story settle down, start dev work Hopefully it's not too ridiculous? |
Marketing from being recognized as a giver is a boost. |
Yes, picking up with planning on #987 ... |
I'm less concerned to do a manual trial run, perhaps because I already experienced that under Gittipay 1.0. I see OpenCollective as having essentially validated this thesis as well. |
|
See further comments at #987 (comment) and #987 (comment). |
|
What is the action item remaining here, @nobodxbodon? Can it be closed now that we have #987? |
|
Removing from the |
|
@whit537 have you checked the major concern a potential company giver has? IMO we need a solution to address that. Besides, I don't know how an OC team distributes their budget as personal income among contributors (if at all?), but as I recall there was one team owner refusing giving from another company as it has conflicts with his contract. If it happens to a lot of project owners with day job, it will greatly impact the user base anticipated. |
Maybe I overlooked, do we have user stories settled down somewhere? |
|
Indeed I did overlook as it's referenced in #987 (comment). I thought we still need to go through them as IMO the scope is too much for stage 1, but I suppose it can be reviewed in that thread. I guess the only remaining concerns is comment above. |
Yup. He provided the solution himself:
|
Anyone on the internet can submit expense reports against a collective. |
I thought he wasn't aware the React was Facebook project. So we had to provide a way to notify people which projects in their dependency list are company sponsored projects. But after I re-read his response, though it's stated
Still he included React in the wishlist:
I still think it's a typo or copy-paste issue, but I could be wrong. |
|
From #987 (comment):
Can we ask someone about this paid out weekly idea? I think that is a new experiment (not the same as one-off). I agree that if Company X wants to give, they probably know how much and want to be invoiced up front about it, just wondering whether they care whether it's paid out weekly or not. The Gratipay way seems to be to pay it out weekly, in order to act as a sustaining gift rather than a one-off. |
They don't. That's clear enough from gratipay/gratipay.com#5. Payout schedule should really be a function of individual preference, though perhaps normalized for easy comparison. This is related to the original vision for #432, to "decouple payins and payouts." Maybe you want to take $1000/mo from Gratipay, maybe I want to take $250/wk—the givers to Gratipay shouldn't need to care about that. I think this line of thinking falls under #991.
Yeah, that's how I'm reading it. Okay! Closing! |
|
Sorry I didn't follow in time. Please allow me to re-open:
There were +1's for giver deciding payout schedule: gratipay/gratipay.com#5 (comment), gratipay/gratipay.com#5 (comment). Either way, gratipay/gratipay.com#5 seems like a blocking feature for #987
If it was indeed a typo, that means, the giver initially overlooked the fact that React was FB project, and after he learnt that fact, he decided to remove it from sponsor list. If so, does it mean we still need to provide a way to notify people which projects in their dependency list are company sponsored projects? |
Let's discuss that on #987.
No, it means he needs to pay better attention. ;-) Besides, it's highly unlikely that Facebook would opt in to receive payments anyway. |
React is actually an obvious case, and sometimes it's hard to see if project owner is paid for the dev work until reaching out to check. Of course we can ask companies to be do more research themselves, but it's the opposite of #987 . If we let company give list, and then let project owner decide whether it's approriate to opt-in, and we only do review to verify the ownership of project (maybe you thought something similar in gratipay/gratipay.com#4297 (comment)?), surely we'll save some burden in short-term, but if there's hidden conflict of interests, when they surface IMO it will influence our brand as collateral damage.
I agree FB will not opt in as a team, but the issue is more about those who are already paid for their dev work may opt in as individual developers (not aware of consequence, etc). |
|
Is it "simple" enough to add some sort of conflict of interest statement to the ToS/application? |
Folded into gratipay/gratipay.com#4389 (comment). |
Though the topic has been discussed in many places for a long while, I've not found a place where we list out all the user stories. As this is such a high-profile task, IMO it's best to get all on the same page, in order to get a more precise idea about the scope and effort, as early as possible. Please feel free to edit as needed, as it'll save time to assemble all stories on the top in one place. Here or another issue may be good to discuss what's the scope of stage 1 (by end of April, before OSCON).
Terms:
User stories
References: integrate npm project, Make it easier for companies to fund open source, latest update.
The text was updated successfully, but these errors were encountered: