If anyone knows #Go and is looking for a project to help out with, Go-based #Signal protocol implementation library and a native #SailfishOS Signal client using it are in dire need of love:
Yes, I also prefer truly decentralized protocols, but Signal is where it's at currently with a lot of people, and it's way better than other popular options... So, we need independent clients.
@rysiek hasn't #Signal demanded people not connect third-party clients to their servers? In fact, any binaries not distributed by them (they refuse to let #FDroid distribute their app). These are only two of many reasons not to support Signal with your unpaid time:
I'd recommend working on a native #SailFish client for #Wire instead. They are a) already close to feature parity with Signal b) actively working towards server>server federation:
@strypey yeah, I am more interested in Briar (time to go full p2p decentralized).
I need Signal for work. It took 3 years to move 200+ journalists to Signal, I don't have 3 more years to now move them to Wire, unless Signal really fscks up big time.
For example, subscriptions to ticket trackers could be sold
You wanna open a ticket ?
You need to buy a 10$ annual subscription
Reading and triaging bugs is work and it should be payed
If that makes you outraged you are probably forgetting the "free" is intended as in freedom, not as in beer
@Wolf480pl feature requests are also useful if you're a developer who cares about #UX, as opposed to one who's scratching their own itch and sharing the results. What would be great is a tracker, where devs could give a time estimate for the feature, and an hourly rate, and users who want the feature could contribute until the required amount is raised. All within the same UI not on a separate site like #BountySource
@AbbieNormal @rysiek @sullybiker
I agree that estimates are weak, but I can think of two possibilities that might also work: one is the devs set a price, and the other that the users set a bounty. Each has pluses and minuses. The big plus is "all within the same environment, not a separate site".
Software production is craftsmanship
What's needed to achieve targets is not measurable.
And it's not a given that users know what they want, or that they share the vision with the devs
I wouldn't overcomplicate because then implementation gets more difficult and you run into overlaps with uman issues (differences in vision, motivation)
You risk this thing to fail and you couldn't even point precisely to a reason why
I'd keep it simple
The community needs to produce some more revenue right now without the need to implement new processes whose implementation would eat up the new revenue produced
I'd try to keep this more down to hearth
Welcome to your niu world ! We are a cute and loving international community Ｏ(≧▽≦)Ｏ !