We should have a delegate whose job it is to identify tasks suitable for community contributors.  For example, quickly off the top of my head and going through the issue tracker, the following aren't considered critical enough to spend much core developer time on right now, don't require a thorough understanding of the code, and would be a great place for a new-ish contributor to get their feet wet:

- Write help documents, blog posts, tutorials, etc. explaining a particular screen or click flow
- Implement robohash server natively in the wallet
- Alternate image sets for robohashes
- Testing, testing, testing!  Explain our test frameworks, write better ones, write tests that expose new bugs or reproduce old ones!
- Find a place where double is used in the code, rip it out and use an exact data type instead
- Test various workflows, such as cold storage
- Find and fix the functions that use too much stack space
- Let collateral vote
- IPv6
- Serialization code generation for multiple languages (perhaps by translating FC serialization to protocol buffers or the like)
- Begin to document our almost entirely undocumented homegrown do-everything library, FC
- Allow UNIX sockets to be used, including passwordless authentication based on user ID like Postgresql

Before I became a core developer, I was a community member.  Some of these were fixes I was considering working on.  I didn't want to put forth substantial engineering effort to write a patch without some reasonable expectation of payment, and bytemaster was leery of promising payment for a product that hadn't been created (and I'm sure I3 budget woes due to AGS funds hurting from BTC price decline didn't help the situation).  Now that I'm a core developer, we've solved the impasse, but most of my time is taken up with pressing issues and new feature development / testing.  I haven't even really had time to set up price feeds or a daily pay withdrawal script for my own delegate!

In early days, there were bounties for many tasks, but I believe this was discontinued when it was discovered that managing the bounties was taking too much time away from development.

So I'd like to see a 100% delegate slot used to fund small, self-contained projects like those I listed here.  The delegate maintainer would be responsible for putting together a list of tasks and awarding payment, community members could bid on tasks, and the core team would have the final say on merging pull requests into official releases.

run Bitshares secure functions (like the wallet) in the browser

Aren't "secure...wallet" and "in the browser" mutually exclusive?

Even though the server doesn't store the user's private keys, in practice the user is effectively trusting the server with their private keys.  For the good and simple reason that, if your browser downloads and runs JS that has access to both your private keys and a network connection to the server that you downloaded it from, what's stopping that server from including evil code in the JS to steal your private keys?

With the existing wallet, you can compile it yourself and (in theory) every last line of  code is public and auditable.  We (or at least I) eventually want to have reproducible builds, so anyone would be able to verify the hash of a binary distribution built with specific toolchain and library versions.

I don't see how the JS version is auditable in that way unless you self-host the JS -- but I assume that the whole point of this exercise is to create a wallet that doesn't require users to install any software.

How would this work?  This would be an important and useful feature which would help us capture really big markets.

My idea for this would be basically zero lines of code.  We'd just make it a separate asset with its own feed, defined to be feed_new_asset = pow(feed_underliyng, k) for a k times leveraged bet.  Changes in the feed make wins or losses in the same direction for the new asset and the underlying, but the new asset wins or loses k times harder because it responds k times more to changes in the feed.

If there's a black swan, at the blockchain level it's a separate asset with a separate feed, so the BitUSD market would be totally unaffected by people trading Leveraged30xBitUSD (well of course there would be economic effects from traders who try to maintain some kind of portfolio of positions in both markets).  In other words, the only people who have to worry about the possibility of black swans caused by the leveraged bets are themselves making equally leveraged bets in the opposite direction.

There's no technical obstacle stopping the delegates from publishing this kind of feed today.  But I'd discourage it right now.  I want to make sure the infrastructure for handling black swans is rock-solid before we encourage creation of assets that are more likely to trigger it.

Didn't see this until it was on the bytemaster blog today [1].  indolering is more connected to mainstream projects than many of us (Mozilla, IETF, others).  He also knows some things about UI / UX, but neglected to mention it in the post.

I'd support him, but he doesn't seem to have actually registered delegate accounts yet.

[1] http://bytemaster.bitshares.org/delegate/2015/01/22/The-Road-to-Universal-p2p-Resolution/?r=theoreticalbts

Many developers would take "equity" in place of salary (ie, not contribute to sell pressure) but if you cannot offer them equity then they will go work someplace else and support BitShares part time if at all.

Rather than having an income of X BTS per round, I'd rather have an income of $Y per round.  The dilution of BTS holders necessary to sustain that level of income will change as the BTS / USD exchange rate rises and falls.  It makes more sense to pay developers fiat-denominated salaries.

The problem is that if you directly use the exchange rate to determine how much BTS are printed to pay people, it could result in an arbitrarily large printing which blows the inflation envelope.   In addition, shareholders should be able to set bounds for particular uses below the envelope -- they may be willing to tolerate N new shares in total, but want to further limit core developers to get no more than M, where M < N.

So I think we should have multiple trusted community members create a multisig UIA, then give everyone who deserves to be paid $Z but is only getting $W from their personal delegate(s), Z - W shares of the UIA.  We don't care that this is arbitrarily inflationary, it's a UIA.

Then we vote in multiple 100% delegates to buy BitUSD with their BTS, then buy and burn shares of the UIA for 1 BitUSD each.  If cap is too low, then the buy-and-burn wall won't be able to sate demand, some developers will be SOL and have to either hang onto their UIA or liquidate below $1 to a speculator at some market-determined discount.  If the cap is high enough, then everyone can cash out their new UIA immediately and start working on their stockpile of UIA representing back pay they couldn't get at the time due to the cap being too low.

If BitUSD becomes widely accepted as an alternative to paying in USD (99%+ of population accepts BitUSD), does this have the same economic consequences as increasing the USD supply? If so, then that means creating more BitUSD should have a direct effect on the value of USD. What does this mean for the peg?

I understand this is probably not going to be a problem for a long time, but I'm just curious as to what people think.

I brought up this point some months ago.  Basically when your BitAsset is no longer small compared to an underlying fiat currency, the network has essentially appropriated monetary policy away from the fiat central bank.

In a future where most of the world's USD denominated wealth is held in BitUSD, if inflation is too high or low, the Fed will want to create or destroy USD, but they will no longer be able to do so to an extent that meaningfully moves prices.  Instead, BitUSD will be created and destroyed according to the supply and demand between shorts and longs, which may result in USD valuations that are sub-optimal from a central bank standpoint.  In particular, the Fed wants USD to have a small amount of inflation with respect to a basket of goods, and be at a level that encourages full employment.

The GUI incorrectly shows all shorts as if they were at the price feed. There is not actually any overlap.

Reported:  https://github.com/BitShares/web_wallet/issues/530

My public key is PTS8BYst4qhSb52MQCXjyLijN2kdk34wwACU6cW5jq5BFjDRpHUy7

The public key should start with BTS.  Does the web wallet actually show this key with PTS prefix under your account as in the screenshot here?  http://bytemaster.bitshares.org/tutorial/2015/01/03/How-to-Register-a-BitShares-Account/?r=theoreticalbts