Well I'm not sure what the most optimal options would be. But here's some important notes to consider/know about:

1. If there'll be a second round of distribution (say to x hundreds users) we'll need to make sure it's plausable first, depending on where we collect the entries from.
For example, if people would vote for giving away ORA to 1000 new BTT users next month without getting flooded with puppets I'd say "good luck". This option need to be realistic. Personally I'd prefer other ways to accept totally new stakeholders, like the video idea.
2. Giving some extra ORA to accounts who are keeping their shares is a very GOOD and reasonable idea IMO.
3. The task I was assigned to do is over (pretty much, say next Thursday). Does this mean I'm going anywhere? NO. But it's something people need to consider. This has also been an extremely stressful time for me personally (nothing at my "IRL" workplace has ever been close to match). I can't promise to manage a second big round for at least 3 months for health reasons (serious). Will I still want to help out with a 2d round if needed? Yes very likely. Do we still have access to the same automatic sockpuppet filtering system as before? Of course. But keep in mind it's naturally not as secure as it was the 1st round now that anybody who applied and didn't make it will surely try other ways to get on the list (some of our edge is gone). Anyway, what I'm saying is just, don't rely on me to collect hundreds of more users anytime soon.

thanks to all for the replies. Any nxt faucet address? Thanks again

@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!

An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.

I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.

@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!

An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.

I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.

Waaaaait. So the people who sold a little are going to be excluded from the new distribution?
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.

Waaaaait. So the people who sold a little are going to be excluded from the new distribution?
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.

@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!

An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.

I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.

You coul do something like this :

Liste C :     balance > 100,000  gets additional  of 50,000
                 balance > 150,000  gets additional  of 75,000
                 balance > 200,000  gets additional  of 100,000
                 balance > 300,000  gets additional  of 125,000
                 ....

keep the rest for later distribution. (3rd round, 4th round,.... )

Possible negative amplifier: dumper(s) buy X ORA to gain Y% bonus over other holders. Then dumps everything after receiving the bigger shares.