
Side-project Ideas That Could Get Big - danicgross
https://pioneer.app/ideas
======
pokoleo
> Reply-to-sheet > You often send emails to lots of people where the replies
> ("yes I can make it!") are collected into a spreadsheet. With your service,
> you can simply CC XXX@your-website.com and have the replies collected into a
> Google Sheet. Make it frictionless to get started. No sign-up should be
> required to create the sheet.

I'm really surprised that evite hasn't done this.

------
newman8r
I'm really curious how many people win each pioneer round. I haven't been able
to find that information. That's actually the only thing keeping me from
participating again (I did the first one and I enjoyed it).

Also your terms of service don't say users are limited to a single account, so
could someone create an account for each of their projects?

~~~
danicgross
1\. We'll be releasing more info about our first cohort of Pioneers soon!

2\. Sure! Just don't do anything you wouldn't do if you were running Pioneer
:)

~~~
newman8r
very cool. I'm going to get my application submitted this weekend. I'm looking
forward to learning more about the first cohort. My original guess was that
you'd select ~10-20 people.

------
mr_puzzled
Feedback to the pioneer team :

\- remove the country and age columns in the leaderboard page. There's no need
for it to be public...privacy.

\- we still don't know what the experience of going through the program will
be like, maybe have a few people write about their experience?

Questions : \- how's the security of the backend used to collect all the info?
A simple page going over what you do to secure applicant data will be
reassuring.

\- how many people applied and how many did you fund?

While these may not seem important to the general public, I'm pretty sure the
average HN user cares about it. As some anecdata : this is basically why I
have not put in an application.

Thanks

~~~
mr_puzzled
Another point : the privacy policy could be improved. Specifically, sharing of
applicant data with 3rd parties. I don't want that at all. When I submit an
application, I expect only Pioneer will have access to it. If you want to send
marketing emails to applicants that's fine, but sharing applicant info with
3rd parties is not cool. Keep it simple like YC's no bs approach. Thanks.

------
nojvek
Why are they against Gmail Auth? What’s wrong with it? I love Gmail Auth. I
trust it far above Facebook and Twitter Auth.

------
gumby
There are a lot of personal CRMs already -- I use busycontacts instead of the
default Apple contacts and that is one of its functions. Look up a contact and
you get the messages and calendar entries about them; you can add notes, etc.

One nice part is it uses standards instead of requiring something proprietary
like gmail.

------
fhars
Yes, I always knew that is just a simple side project to reliably measure
software engineering productivity. It is probably as simple as counting the
lines of code produced in a given day. /s

~~~
citrablue
I think the "side project" framing actually makes this problem more solvable,
because you don't have to completely solve every aspect of the problem. It
seems likely that developing an easy to measure metric would start to help the
issue, which is what Pioneer may be looking for.

E.G., measure the productivity of repo owners (managers/leads) by their lag in
accepting pull requests. Measure the quality of submitted code by comparing
how often my code is accepted compared to someone else's (w/in the
organization/language/community).

From there you could build more of a productivity measurement suite, e.g.
maybe connect test coverage and bug reports to specific commits and start to
score a coder.

Basically, look at currently-existing data points about coders that a specific
team culture believes are important to productivity. Then baseline that
against a comparable group, and present reports.

Another trick is to simply measure stuff over time. (This is a bit trickier,
due to what you hinted at w/ LOC... but still measures change over time, which
is really useful for managers.)

The final thought I have is that it is useful to connect events over time that
are related to the same code/feature/branch. If my team's workflow is
design/develop/test/commit....gap....deploy to users, then bugs are temporally
disconnected from development efforts. Connect things over time in an easy to
use report, that has value.

