Jake: Establish plan for disbursing community-raised funds #14
Comments
|
Some ideas I had for potential projects might include:
While big things like implementing federation, supporting social protocols, and implementing backup are super valuable to the long-term success of Sandstorm, I feel like we should tackle some short-form hits to get our community funding moving. |
Generally agree. Also, said big things sound fun, so it's more likely I'll end up doing them for free at some point anyway. Do we have an issue open for "change packageId"? I can thing of some use cases, but this probably needs a decent bit of design discussion. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Agreed. I will work on writing up some issues for these. (Also, "hiding" our last two posts, I don't want them to dominate the discussion here.) |
|
1a) Would it be possible for some sponsored Sandstorm developer to send pull requests to Sandstorm and Wekan to fix some of Sandstorm Wekan issues like: I think I don't know enough about Sandstorm internals to fix them myself. 1b) Alternatively, could someone add more tips to those Sandstorm Wekan issues where to find more related documentation, code files at Sandstorm repo, examples, etc to help me solve those issues.
|
|
@xet7 Yeah, we'd need to define the scope well, but adding more Sandstorm integration to Wekan could be a viable project here. |
|
Ok. I'm mostly interested about that above 1a) User Permissions, to get that working. |
|
I'm gonna tag in a couple people I specifically hope see this thread: @abliss @troyjfarrell @garrison @dckc |
|
Possibly another feature that might make sense for consideration here is dark mode, as Sandstorm is probably the last web property I use which doesn't support it. Though I am unsure the scope of this, if it requires "edit every template", it might be a longer project than I'd hope. |
|
The most important thing to me is that Sandstorm remains a viable and improving platform. Second, improvements to apps would go a long way to improving the Sandstorm experience, I believe. Updating the versions of Etherpad and Overleaf was suggested above. I wish that Sandstorm had alternatives to Doodle and Disqus (e.g. isso, commento). I occasionally come up against bugs in davros that ought to be fixed. My third wish would be better backup support. |
|
Quoting Jim Garrison (2021-06-28 20:56:19)
alternatives to Doodle
Have you checked out Framadate?
|
|
Re: disqus, I experimented with my own variant of this way back: https://github.com/zenhack/sandstorm-comments though I think I hit some design roadblocks, but at this point I forget what they were... |
|
I think the biggest one for me is first class support for ARM64 and raspberry pi. Sandstorm is attractive to me because I think it's a great platform for small homelabs, rather than being deployed on cloud servers. So for me, this isn't just about privacy-first design, but also better resiliency of our computing infrastructure that our civilization uses. I think the Raspberry Pi would make for a better hardware platform than x86. |
|
Would folks please refer to your important things by issue number? If there isn't already an issue, add one? Oh... maybe I see why this is a challenge. I was going to point to the backup issue, but there are many. #8 looks pretty cool. my thoughts as a customer are in dckc/madmode-blog#83 |
|
@hosh I think that's the natural place to end up now that ARM boards powerful enough to run Sandstorm are plentiful, though it's probably substantially more work than I expect us to accomplish in near term goals. As far as I can tell, Meteor still doesn't officially support ARM. And the most critical issue will be that every app likely has to be repackaged for ARM-based systems. x86-based hardware is plentiful on the low-end too, either via old servers or budget-spec mini-PCs. @dckc For what it's worth, there's a bit of project brainstorming here, but it's also to discuss the approach to handling the funding. If it seems plausible to move in the direction I put in the original text at the top, we'll have to triage the suggested ideas into time/value expectations, then assemble a polling strategy for people to indicate support... probably with links where appropriate to more detail. |
eh... last I looked there was still a pretty huge price gap between something like the rpi and a cheap intel anything. But yes, ARM support is a much bigger task than the scope we're looking at for these funds. If folks want to direct the resources in that direction, it would make sense to break off some smaller prereqs I think. #4 is relevant here, as the seccomp filters are the one major bit of "code" that is intrinsically architecture specific -- so I'd want to get that nailed down before I try porting it to a new architecture (note that the flatpak folks at some point used our code and erroneously assumed it was portable: sandstorm-io/sandstorm#3402). An "ARM Roadmap" might be useful for planning more broadly |
This comment has been minimized.
This comment has been minimized.
|
(Let's avoid hijacking this thread to discuss the merits of an ARM port in detail; we have an issue dedicated to that). |
|
Okay, so we've left this open for a bit, I think we should sort our projects into: Continuing efforts to work on (these fall a bit outside the scope of what we can accomplish in this short term, but my hope is if we can build recurring funding, we can establish a set of sub-goals to accomplish to reach each of these):
Shorter-term projects:
@zenhack I know you aren't available full-time at present, but based on your knowledge of some of these issues/projects, do you think you could estimate the number of full-time weeks you'd expect these shorter-term projects to take? I kinda want to establish some sort of rough baseline of "this is going to take twice as much as this" from this. |
|
I'll find time and give it some thought soonish. Re: the commenting app, this feels like something that's going to need a bit of research before I can pin down a reasonable estimate. Agree that the Davros thing isn't actionable yet. |
|
@zenhack Yeah, if there's anything you don't think you can reasonably estimate or handle in a short timeframe, we can punt if needbe. @garrison Do you think you could highlight an explicit group of problematic bugs or high-impact improvements that would make a good Davros update goal? (We'd also need @mnutt's involvement, so I should probably tag him if we're talking about it.) |
|
Regarding Davros, I wish that it would be more resilient to files with arbitrary names and files with arbitrary content. For an example of a grain becoming entirely unusable based on the content of a single file, see mnutt/davros#117. Regarding filenames, I was recently unable to view a single file named |
|
Here are some stabs at rough estimates on these issues. All of these should be considered somewhat tentative; I'd probably want to do a more methodical think about each of them before agreeing to an actual quote: These are hard to say exactly, since there are a lot of unknown unknowns, but almost certainly less than a week:
Note that the former I started on a while back: https://github.com/zenhack/etherpad-lite-sandstorm; it even builds and works, but it's slow to start and is missing some plugins and integration -- I wouldn't consider it ready until it's clearly not a regression. There are a bunch of patches applied to the original package which I will have to tease out and add to the new one. I have a strong suspicion that @xet7 would be more efficient at solving the Wekan issues than I would, though I could advise on Sandstorm platform questions. The multiple board issue smells thorny. I don't really want to comb through all of the other issues individually.
The big caveat with the Davros stuff is I'm not really familiar with the codebase; there's always the possibility I get in there and it's structured in some wild way I didn't anticipate or (in the case of the bugs) the issue is much subtler than I'd expected. So the above should be taken with a hefty grain of salt. Commenting app that works on Sandstorm: Really hard to estimate; this smells like the sort of thing where there might be some architectural gotchas, given that the comments are supposed to be pulled in by another page. I'd want to dig in and map out the design space before attempting to asses the workload here. Add Powerbox visibility/revocation to Grain Settings: I'm assuming this is just listing the caps that the grain holds, and adding a "revoke" button. This will take less than a day. Add grain transfer to Grain Settings: a few days to a week. Add change package to Grain Settings: a day or two |
|
Yes, I think it's better for me to look at Wekan issues, and only ask about some specific questions about Sandstorm I don't know yet. |
|
@zenhack I think there's probably value in the Wekan item as a small project even if it's maybe just a concentrated effort to work with Lauri on it. The Sandstorm integration code is mostly all in one file, and a lot of it was written by David Renshaw (https://github.com/wekan/wekan/blame/master/sandstorm.js) Right near the top of it is a comment stating the no-longer-the-case assumption that only a single board would be available in a Sandstorm grain. Some of the other questions like API integration is probably mostly troubleshooting: Wekan has an HTTP API and Sandstorm supports such, but there isn't a working implementation. Depending on Lauri's comfort being paid out by an OpenCollective, we could also perhaps split the project between the two of you if it entails you working together. I'm going to ponder over your estimates and maybe pitch out where I think maybe the numbers should be, and see what you think. We are coming up on a month since FundOSS, and I'd like to have some sort of plan and send out an update to both start people voting on how we should prioritize these and encourage recurring donations. (Along with perhaps some project-based buckets in OpenCollective to build funds for larger projects.) |
|
Yes it's OK to work together. It's OK for me with OpenCollective, or anything else. It's just that I have not used it myself yet, so you providing details helps. |
|
I'm not so good with estimates, so it's better you think about those. |
|
At that Sandstorm Wekan permissions related code is mentions about them being hacks, so maybe there could be some better way to implement those. |
|
Also, currently there is Wekan Teams/Organizations in progress, so there's some thinking how it would work with Sandstorm permissions. Although, it's basically just in Wekan Admin Panel adding some Sandstorm user to Team or Organization, and then at boards adding some board to Team or Organization. I don't know does it need to affect Sandstorm in some way. |
|
I unfortunately don't have the bandwidth in the next few months to do very much development on Davros, but am happy to assist others and help make sure that changes get incorporated. |
|
@zenhack Do you think it would be fair to set a price of roughly $750 for each app project (Etherpad and Overleaf repackages, Davros and Wekan fixes), and maybe $250 to each Grain Settings feature, with perhaps the note that if something ends up being significantly more complicated, we might add $250 to a given item? (Or perhaps a stretch goal, like ensuring smooth upgrading for Etherpad and Overleaf... the former I suspect will be really irritating, but the value of it is high.) That would give or take divide about the funding we have over most of the projects mentioned here, and give a bit of extra weight to the app projects, which may require diving into less familiar codebases and/or being just very boring work. @mnutt That's all we could possibly hope for. The biggest frustration would be if we got the work done, but couldn't get a release out. Thanks! |
|
Those numbers sound low. My usual corporate rate is $120/hr. I'd be
willing to cut that to $90/hr for Sandstorm community stuff, but I can't
justify going any lower than that, esp. given other demand for my work
right now. at that rate $250 works out to a bit less than 3 hours of my
time. The estimates I gave above were intended to be a bit conservative,
but not *that* conservative.
Additionally, I usually charge extra for flat fees (generally in the
form of a bunch of extra padding); a more generally cost-effective way
of heading off unexpected expenditures is to have a periodic check-in
interval, where we pause and have the opportunity to bail/change plans
if things are turning out to be more work than we anticipated.
(Also, I'm not really sure what there is to do on this front that's
actionable, but I feel the need to state my general uneasiness with
my position in all this; I'm an admin on the opencollective account,
and being involved both on the fundrasing/decision making side of
things and also possibly being hired to work on stuff feels very
awkward, to say the least. I don't know what to do about it besides
radical transparency and deference to anyone who speaks up. I kinda
wish we had someone else interested in working on this stuff, and
I think in a broader context we should be thinking about ways of
broadening the pool of people we can tap for this kind of thing).
…-Ian
Quoting Jacob Weisz (2021-07-26 23:30:30)
***@***.*** Do you think it would be fair to set a price of roughly
$750 for each app project (Etherpad and Overleaf repackages, Davros and
Wekan fixes), and maybe $250 to each Grain Settings feature, with
perhaps the note that if something ends up being significantly more
complicated, we might add $250 to a given item? (Or perhaps a stretch
goal, like ensuring smooth upgrading for Etherpad and Overleaf... the
former I suspect will be really irritating, but the value of it is
high.) That would give or take divide about the funding we have over
most of the projects mentioned here, and give a bit of extra weight to
the app projects, which may require diving into less familiar codebases
and/or being just very boring work.
***@***.*** That's all we could possibly hope for. The biggest
frustration would be if we got the work done, but couldn't get a
release out. Thanks!
--
You are receiving this because you were mentioned.
Reply to this email directly, [3]view it on GitHub, or [4]unsubscribe.
Verweise
1. https://github.com/zenhack
2. https://github.com/mnutt
3. #14 (comment)
4. https://github.com/notifications/unsubscribe-auth/AAGXYPU7E5MSC7EF2W625ULTZYR5NANCNFSM47KWZSHQ
|
|
Those are definitely all fair points. My rough-ish thoughts were that it might land far south of corporate hourly rate territory, but be well above the previous GitHub Sponsors' monthly level. (And FWIW, from a financial/practical standpoint, I would probably always recommend prioritizing your higher-tier corporate rate work when it's available... Ian being able to afford food is just a inherent positive for the Sandstorm project.) I also agree it would be more comfortable if there was more input on both the community spending angle, and the potential contractor angle. I have tended to look at things from a bounty model before, which is by nature flat-fee, but the nature of OpenCollective and "invoicing" work would naturally fit an hourly rate model. So I guess then the question would be, would the community here be comfortable with that direction? If so, would we set a consistent hourly offering for any developer working on it? Or how would the community decide that Ian's proposed rate is fair? The numbers I ballparked would presumably come close to a notion where the existing raised funds would cover most of the list of project ideas. Presumably whether at an hourly rate or a higher flat fee, the scope of work able to be reached within the funds raised would be less than that, which I suppose makes the idea of voting to prioritize projects somewhat more noteworthy... Ultimately I'd like to get to the point where we are both moving on the community selecting what projects are going forward first, and we are beginning to solicit recurring support in order to be able to afford more. Ultimately, with you not able to make decisions to conflict of interest, and me being absolutely not willing to make decisions about community funding entirely on my lonesome... We really need other people's thoughts on this... |
|
Hmm? So maybe, I'll do that everything listed, and then that money to me? 🙂 |
|
@xet7 It'd definitely be excellent to have multiple people working on Sandstorm via this funding! My thought was if you and Ian worked together on the Sandstorm integration issues with Wekan, for instance, you could both get a portion for it. But we need to figure out what is fair and under what terms it should be handed out. |
|
Yes it would be nice if other people participated too 🙂 Anyone available that has some time for it ? |
That sounds fine to me. A primary goal from my perspective is to keep morale up among developers, and I expect that hourly with regularly check-ins has advantages on this front.
Setting a consistent and general policy here is, of course, difficult. I wouldn't necessarily say that every developer has to be paid the same rate. But if not, this must be done with great care. The way I think of it is as follows: essentially, Ian is quoting his opportunity cost for taking on projects. For projects that take advantage of his current knowledge and experience working with Sandstorm, it probably makes a lot of sense to hire him. This would certainly include the Powerbox visibility/revocation to Grain Settings project above. I also like the idea of Ian providing help fixing longstanding Wekan integration issues, especially since the Wekan port has been well maintained and seen consistent releases over time. At the same time, I am not really sure that it makes sense for us to pay Ian his quoted rate to dive into an unknown codebase (Davros) and fix random bugs (the ones I suggested above). Updating the Overleaf or Etherpad packages would, of course, be a huge win. If there are no other bids, the most logical path forward might be to have Ian work on (one of) them. |
|
I also just want to say a few words about my experience so far in contributing financially to Sandstorm development through GitHub Sponsors after Oasis shut down. I became a sponsor of Ian after seeing Jake's message on sandstorm-dev, motivated primarily by the matching funds, but with overall low expectations, only the hope that I could send a clear signal that I want Sandstorm to continue as a viable platform. When TTRSS was updated, I was confused the first time I opened my grain and received all the PowerBox requests, but once I then read the post on the Sandstorm blog and understood what I had witnessed, I was ecstatic! I also really appreciate Ian's work on the Content-Security-Policy stuff, as well as numerous other contributions. The primary reason I contributed to the FundOSS campaign is to express my gratitude and excitement that Sandstorm is still moving forward. |
|
I've made a Framadate poll here: https://ocdhost.sandcats.io:6080/shared/NC8FAJpQU5kb7ZoWThCV679FlD4Gd5TpnmFuFxQmhti While shy of ranked-choice voting, this does let you effectively group your preferences into three groups: High Priority, Low Priority, and Not Interested, give or take. I added the seven relatively well-defined projects that we can reasonably estimate the time frame for completion. If people would like to vote from this issue, feel free to do so. If you object to this voting method, please comment here, and if there's no opposition, I will post this to the mailing list and OpenCollective in the nearish future to try to get a wider net of participation. |
|
@garrison You may want to check out the new version of Davros in experimental: https://apps.sandstorm.io/app/8aspz4sfjnp8u89000mh2v1xrdyx97ytn8hq71mdzv4p4d8n0n3h?experimental=true |
|
It looks like the powerbox controls are tied for the lead right now. I feel like we need to pin down exactly what functionality that entails. Also, we should make a call on how long we're going to keep the poll open. I won't have time to work on stuff until September in any case; currently doing stuff for a client who is in crunch mode. |
|
@zenhack I think my intention for that item was that Powerbox requests which have been granted (say, domains TTRSS is allowed to talk to) are listed in grain settings in an understandable way, and the ability to revoke those capabilities is available. I'm not sure there's any more sophisticated controls necessary or even desirable. Are there presently other types of Powerbox requests that might need to be covered there? (I'm not particularly versed in the internals of that.) Honestly, the poll is probably reaching it's natural end (time since the emails/posts about it went out, the people who voted are mostly those I would expect to participate, etc.), I think it's probably safe to consider these the standing priorities for now. I am not super worried about someone in our community calling the process unfair because we didn't adhere too tightly to a explicitly given timeline or process. And this is really just the first phase of this, as hopefully we will regularly build funds, solicit feedback on projects we should try to schedule, etc. So things missed or left out or not accomplished during this one will make it in the next one. So our top priorities would be the Grain Powerbox Controls and the Etherpad Re-package. And once those are accomplished, as funds permit, Grain Ownership Transfer and the Overleaf Re-package. I highly doubt even if a few more people pop in to vote, that order is going to change much. |
|
Hey everyone, we are going to get this moving here. Ian still has other projects taking up a significant portion of his attention, but we have sought out another person to start moving on our community's goals. We've been speaking with @orblivion, who is uniquely qualified to work on the Etherpad re-packaging project. Dan is both a published Sandstorm package author, having put together the very well crafted Kiwix package, and has done contract work on Etherpad relatively recently as well. Dan has done some investigation and estimation on the work required to re-package Etherpad, with a range of between 17.5 and 44.5 hours. Our plan is for Dan to begin work on the update at the same $90/hr. rate discussed above, checking in with the community at the end of each 10 billable hours. (I think perhaps an issue on the community-project repo may be a good way to do this, so interested parties can subscribe.) As long as we feel we're on track, we'll give Dan the go ahead to continue. |
|
Thanks @ocdtrekkie! The estimate is split into several different areas of concern (plugins, sandstorm integrations, etc). Some have a bigger estimate range than others, accounting for very optimistic vs very pessimistic view of unknown unknowns. I was thinking I could front-load those areas so we could hone down the estimate faster, and perhaps know sooner if we want to short-circuit if it starts to look like it'll go really long. |
|
Yeah, I thought the analysis you did was very thorough, thanks. Do you want to share the breakdown here so others can see it? I agree with the idea of tackling the less-certain tasks first. |
|
The estimate might be a good opening post for Dan's tracking issue for his work, so we can move status of that project out to it's own issue. |
|
Good idea. |
|
BTW I have even more detail than this but I kept it as my own dev TODO items for everyone else's sanity. But LMK if anyone wants more detail on something. |
|
I'm going to close this one since we have a plan, including having spent a large portion of what we raised, and a list of community-prioritized items to spend the rest of it on. |
Thanks to FundOSS, our OpenCollective now has a sizeable $4,878 to work with to fund Sandstorm development. I think that it's critical that we translate this funding into progress in short order, so that people feel their investment has actually gone to where it belongs.
My understanding is that FundOSS intends to run another round in 3-6 months, which I feel should guide our disbursement rate somewhat, though until the next FundOSS is running, we should assume it may be a one-off, and try to raise our own recurring funding on OpenCollective. But if we were so lucky as to be able to run FundOSS again and come out similarly in 3-6 months, then we should look to spend $750-1,000 a month.
I think we should establish a list of appealing projects that can be completed in roughly a month or less, and assign a rough dollar value, based on the expected time needed and our goal disbursement rate (above). We should then determine a way for the community to indicate their preferences/ranking, such that we can prioritize spending on projects which the community is excited about. I think Framadate might be a suitable poll app for this, since people can vote for multiple options, though it falls short of ranked-choice or single-transferable voting.
Obviously the two biggest perks to running community funding this way compared to Ian's sponsors page is: We can easily distribute this to any community developer participating, and the community can direct the priorities of development rather than leaving it open-ended.
The text was updated successfully, but these errors were encountered: