What are Github commits?

[gamey]

Charles deleted his account.  Oh my !  Oh well Charles, I hope you grow a thicker skin.  If you'd been in Dan's shoes you would have gotten it 10 times worse this past year than me being cranky.

[gamey]

I guess we are at an impasse. There is really no point in continuing the convo. I'm truly sorry gamey that you have such a negative opinion of me. It doesn't change the reality that Invictus raised millions of dollars in a way that had no accountability attached (by their own admission), the founder who remained has spent all the funds raised (by their own admission), and Bitshares 1.0 still hasn't shipped. At this point Ethereum may have a stable release prior to the Bitshares client. At what point is there a problem? At what point do changes need to be made?

But I guess it's easier to criticize me than take a cold hard look at what has happened over the last year.

Cheers

I agree multiple things were a mistake and I agree with you on many points but my list is still distinctly different from yours.  I have specific gripes and they've all been mentioned elsewhere.  A person can throw about all sorts of solutions after the fact and sound like they would have done better.  Perhaps they would have, perhaps not.

I would just like you to be honest in your assessment.  4 million, yet at the end of the year that 4 million was worth half as much.  Yet lets never bring up how the volatility of BTC hurt the project more than anything and keep harping on the 4 million figure.  It is stuff like this that makes me have a negative opinion of your input.  Sometimes I think you write very useful posts, like your original post in this thread.  However that just ended up being the inevitable lead up to taking shots at Dan's leadership.

Personally I sort of wish you had stuck around and these problems never started.  I suspect BitShares would have had a more solid fanbase if you had stayed on the project.  You seem to be very good at making connections etc.

edit - LOL good catch on quoting Dan.  I dunno, I went to AGS explorer and it said about 5300 BTC.  At $300 per BTC that isn't near 4 million. 

[charleshoskinson]

I guess we are at an impasse. There is really no point in continuing the convo. I'm truly sorry gamey that you have such a negative opinion of me. It doesn't change the reality that Invictus raised millions of dollars in a way that had no accountability attached (by their own admission [1]), the founder who remained has spent all the funds raised (by their own admission [2]), and Bitshares 1.0 still hasn't shipped. At this point Ethereum may have a stable release prior to the Bitshares client. At what point is there a problem? At what point do changes need to be made?

But I guess it's easier to criticize me than take a cold hard look at what has happened over the last year.

Cheers

[1] -> "...AngelShares are an abstract notion, are non-transferable, and do not represent a legal contract amongst Invictus and those who send a donation. The worth of owning AngelShares is derived totally from the social contract enforced by voluntary actions of these who participate in the market place." http://cryptocoinupdates.com/invictus-innovations-announces-initial-launch-of-angelshares/

[2] -> "...Overall we raised about $3.6 million in AGS donations and now that these bonuses have been paid we have spent $3.6 million in 2014.    We had a large capital-loss on our BTC holdings and an offsetting capital gain on our BTS holdings.    Of the money we spent, 10% went to China, 10% went to US Marketing (conferences, videos, website, travel), 7% on FMV.   Our largest expense category was developer salaries and grants including ~$100K for Toast and ~$100K for HackFisher as well as salaries for over a dozen different developers." -> https://bitsharestalk.org/index.php?topic=12806.msg168469#msg168469

BTW notice the fiat quotes come from Dan not me. Furthermore, add the 575k that came from Li and that's over 4 million USD.

[gamey]

There is no doubt that a solid testing framework/methodology benefits software if it doesn't remove resources elsewhere. Duh! That is not what is being argued. I'm saying that everything is a trade off. Apparently Toast thinks that more resources should be moved into testing.  Well ok.  As long as you guys have the spare cycles then Toast would know.

Jesus, do you even read the drivel you write?

Yawn. I read my drivel along with yours.

I could see you setting yourself up for your spiel as soon as you asked thom if he worked on the software.  You are too obvious. 

You then went on with your typical jargon pumping.  I wouldn't have a problem if you'd just criticize, but you criticize things that you know little about.  I understand you worked with I3 a year ago, but they were barely programming.  Yet you extrapolate from that experience.  Just ridiculous.  Yes, a test driven release cycle/development process would be an improvement over what was in place at one point, but thats not my issue.  Having a test team with a build engineer and regression testing and all that is great, but it costs resources. 

So a guy like you sits back and says "Oh you need this and that !"  but wait "you spent way too much money" (while consistently quoting a misleading amount actually spent).  And to me I just want to bang my head against the desk because too many will eat up your bs.  Thats the thing though, it isn't really bullshit, it is just a lot of jargon that has applicability but in reality it says little.

[charleshoskinson]

There is no doubt that a solid testing framework/methodology benefits software if it doesn't remove resources elsewhere. Duh! That is not what is being argued. I'm saying that everything is a trade off. Apparently Toast thinks that more resources should be moved into testing.  Well ok.  As long as you guys have the spare cycles then Toast would know.

Jesus, do you even read the drivel you write?

[gamey]

There is no doubt that a solid testing framework/methodology benefits software if it doesn't remove resources elsewhere. Duh! That is not what is being argued. I'm saying that everything is a trade off. Apparently Toast thinks that more resources should be moved into testing.  Well ok.  As long as you guys have the spare cycles then Toast would know.

[charleshoskinson]

Example http://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to/

[sschechter]

FWIW I agree with charles here and BM's listed improvements were because vikram and I bitched about it.

 

A properly implemented agile process will improve the teams performance.  A poorly implemented process will get in the way and slow things down.  Keep agile flexible and do what works best for the team, and not what a bureaucratic layer in management wants.

[toast]

FWIW I agree with charles here and BM's listed improvements were because vikram and I bitched about it.

[gamey]

You don't ad hoc cryptography, consensus and economics. Damn it guys. Believe whatever the hell you want. I'm out of this convo. Testing doesn't slow things down. It saves countless hours of future debugging. I'm sorry you can't understand that.

epic rofl.

The fact is you can test too much or test too little.  It is all tradeoffs and finding what is optimal given your specific situation.  Charles is great on blowing up clouds of authoritative smoke, but reality is things aren't as simple as just throwing out buzz words.

[charleshoskinson]

You don't ad hoc cryptography, consensus and economics. Damn it guys. Believe whatever the hell you want. I'm out of this convo. Testing doesn't slow things down. It saves countless hours of future debugging. I'm sorry you can't understand that.

[bytemaster]

Lets see here....   

We have a full time test developer that has promised me one test per day on average.   

We write tests that reveal a bug, then we fix the bug.   

We have implemented a phased release cycle with dev shares and are focusing on scrum style milestones.   

Our process is maturing, but it has slowed things down. 

[gamey]

The layers I recommend actually save money and time and dramatically enhance development quality. Being on scrum means you focus only on the features that are actually connected to real problems and have a process to release them in a systematic, structured way http://m.youtube.com/watch?v=XU0llRltyFM.

Adopting a process like test driven development means you have an emphasis on some collection of testing processes for each commit that ensures certain classes of bugs don't creep into the code base. This saves enormous amount of time in debugging after the fact. http://youtu.be/O-ZT_dtlrR0. It's easy to do, lightweight and every single major software company does it.

As for infosec audits, you do it twice per major release. Am initial audit and a post audit to see if you fixed the security holes. Cost should be around 50-100k.

I've run or participated in several software projects in my life and seeing 4 million dollars be spent so quickly and for what has been delivered is beyond me. There isn't a clear architecture, the protocol isn't stable, the core software is terribly buggy, there is little documentation, and again many things have been designed on an Ad Hoc basis.

You really have no idea if these processes would help or hinder.  Scrum usually has a dedicated customer to interface with.  If not, then someone else has to take on these roles. Yes, more testing could always be done, but that requires less time coding.  Just because it is claimed doesn't make it true.

If you don't design anything on an ad hoc basis, then that means someone has sat around thinking out the whole thing from soup to nuts.  That is quite time consuming.  Like I said ... your criticisms don't even fit together.  Should they have sat around and spent more money and got less done?

The 4 million number you like repeating, I'm likewise not so sure about.  BTC dropped in USD and when I multipled BTC donations out by the price at the end of last year I didn't even get 2 million. If your criticisms were honest, I don't think you'd stick with the 4 million figure. 

I've worked for software R&D houses that got 5 million government contracts YEARLY and the software they produced was seriously LOL compared to the bitshares client.

[charleshoskinson]

The layers I recommend actually save money and time and dramatically enhance development quality. Being on scrum means you focus only on the features that are actually connected to real problems and have a process to release them in a systematic, structured way http://m.youtube.com/watch?v=XU0llRltyFM.

Adopting a process like test driven development means you have an emphasis on some collection of testing processes for each commit that ensures certain classes of bugs don't creep into the code base. This saves enormous amount of time in debugging after the fact. http://youtu.be/O-ZT_dtlrR0. It's easy to do, lightweight and every single major software company does it.

As for infosec audits, you do it twice per major release. Am initial audit and a post audit to see if you fixed the security holes. Cost should be around 50-100k.

I've run or participated in several software projects in my life and seeing 4 million dollars be spent so quickly and for what has been delivered is beyond me. There isn't a clear architecture, the protocol isn't stable, the core software is terribly buggy, there is little documentation, and again many things have been designed on an Ad Hoc basis.

[gamey]

Furthermore, the development cycle is not well managed. There isn't a proper testing process in place, no method for new developer integration, major components of the system have been designed on an ad hoc basis, the code hasn't been audited by someone with a serious infosec background, etc etc. I could keep listing problems, but what is the point? Bitshares is an echo chamber. Dissent has already drifted away.

It is humorous to me how you harp on how Dan wasted a lot of money but then in the next breath you add all these layers of processes that should be created.  To me it makes zero sense but others see your contributions differently.

[CLains]

As the project broadens and moves away from the current dictatorship, then I suppose there will be potential areas I could contribute if they make sense. 

Bitshares is an echo chamber. Dissent has already drifted away.

Dissent did not "drift away," in fact many of the core members here have been just as critical as you or Adam or whoever else. Both Toast and Agent86 - who are now employees - started out as ardent critics, driven almost as much by passionate annoyance with core decisions as with admiration for the project. People stick around because despite all the flaws, BitShares is still the best project in town.

It does not matter now who developed this thing - if you convince the shareholders that you produce more value than you consume you get voted in. The BitShares community displays above all the trait of great entrepreneurs, i.e. disagreeableness, which just means that people here are rugged individuals who don't have it in them to be socially sensitive.

[charleshoskinson]

I wish you would consider joining a mumble session. A good portion of this conversation is about the free exchange of thoughts and ideas, why not come share some with us. Not only that but I think you would probably make a certain fuzz a very happy happy guy.

The last time I joined the mumble server, the room was password protected. This aside, as long as you have Dan at the helm, realistically my ideas are not going to be adopted, considered or perhaps even entertained. As the project broadens and moves away from the current dictatorship, then I suppose there will be potential areas I could contribute if they make sense. 

I recently grabbed the attention of an extremely talented/experienced developer/engineer , with 30+ years experience. (I've been working on him for a year now)  He's interested in contributing but the best I could tell him about getting involved was to join the forum or check out the github.  The wiki is dated and many elements are MIA  even the Whitepapers seem to be missing.   I'm not aware of any better sources to direct him to as far as a framework, clear documentation, project goals/milestones, how to participate etc, or even who to contact that's in charge of such project organization( i assume bytemaster, but I don' know).   I'm not a developer so I don't have any experience on how these things are generally managed especially in an open source, decentralized project, it does seem like it could use improving, from my limit perspective.

Accessibility to all those who wish to join should have been a top priority since AGS was launched. Apparently spending hundreds of thousands on Brian and Co alongside numerous unnecessary conferences was a higher priority.  I think the greatest irony is that Brian actually made more money than I made during my entire time at Ethereum and Invictus combined.

It all aside, the job isn't that hard. You ask what problems do we solve? Who cares about these problems? Why are we better than the other solutions? Where are we weak? Who can partner with us? How do we ensure sustainability. It seems like no one bothered to do a business model canvas or even a cursory market analysis. Had it been done, then almost immediately, one could have recognized that conferences were worthless, meetup groups had much more impact, and that the core concepts were terribly unclear to most people without weeks of exposure.

Furthermore, the development cycle is not well managed. There isn't a proper testing process in place, no method for new developer integration, major components of the system have been designed on an ad hoc basis, the code hasn't been audited by someone with a serious infosec background, etc etc. I could keep listing problems, but what is the point? Bitshares is an echo chamber. Dissent has already drifted away.

[Xeldal]

Being on the inside and then on the outside, I suppose I have a different perspective. So far 4 million dollars has been spent and there isn't a stable client nor a clear development roadmap and testing process. I don't believe the current team is using a methodology like scrum nor have I seen any clear documentation on core pieces of technology like the consensus algorithm, titan, how the crypto is implemented, etc. Furthermore, there seems to be a family of projects all leveraging the same codebase, but I'm unclear on the relationships between them and also how this impacts developer resources.

To me rich documentation is incredibly important to all open source projects. For example, look at api.jquery.com or zeromq http://zeromq.org/intro:read-the-manual, which I consider to be very well run projects off of a pretty minimal budget. Second, there has to be a framework for how outside developers can understand the project, its goals, and how to participate. Bitcoin has BIPs that yield a great degree of controversy, yet they still have a system for proposing and specifying new features and functionality. I'm not aware of anything like this from the bitshares team. 

Great points Charles.  I can identify with this, albeit from a very limited perspective.

I recently grabbed the attention of an extremely talented/experienced developer/engineer , with 30+ years experience. (I've been working on him for a year now)  He's interested in contributing but the best I could tell him about getting involved was to join the forum or check out the github.  The wiki is dated and many elements are MIA  even the Whitepapers seem to be missing.   I'm not aware of any better sources to direct him to as far as a framework, clear documentation, project goals/milestones, how to participate etc, or even who to contact that's in charge of such project organization( i assume bytemaster, but I don' know).   I'm not a developer so I don't have any experience on how these things are generally managed especially in an open source, decentralized project, it does seem like it could use improving, from my limit perspective.

[theoretical]

I am trying to get a working understanding of what commits actually are and more importantly if we as users/shareholders can use them as some sort of metric.

Ultimately, really understanding what a commit represents entails understanding how Git works as a distributed version control system, and the different possible workflows enabled by Git.  Which you probably won't really understand until you've used Git for a while, including contributions to larger projects.  (At least I didn't really understand until I'd used Git for a while.)

We can help give you an idea in this thread, but the idea will necessarily be simpler than the reality of the different ways different people and projects use commits.

No commits means they are not writing code.

Not necessarily.  You can have code that isn't ready to go into a commit, or you can have commits locally that you haven't published yet.

I like to clean up my commits before I publish them.  Nobody's interested in the 10 different one-line typo corrections and insertion / deletion of temporary debugging code I had to make to get my brand new code to compile and run as expected for the first time, so putting that kind of crap in the public commit record on Github as 10 different commits accomplishes nothing except wasting the time of everyone who views them and artificially inflating my "number of commits" metric.

So for this reason, my published commits aren't always an up-to-date record of the work I've been doing.

[Gentso1]

"The project raised over 4 million throughout its history and I was able to get Koblitz and Merkle to join ethereum prior to even a fraction of that funding. I think that good projects are able to attract great minds if the ideas are accessible and there is an emphasis placed upon collaboration. Vitalik established a wonderfully collaborative environment for people to join Ethereum, do you feel the same has been done for the developers behind bitshares?"

Your ability to get people excited about projects is well known and recognized. You have been able to exercise  this talent across a few different projects and I think it has just as much to do with you as it does the project in question. I believe your background as a mathematician coupled with the ability to speak well makes you a great talent scout and a unusual mix of talents. 

To answer your question, Yes I do. I think the evidence is here in the forums. As time has past and even more so of late we are seeing people with a range of talents being attracted to Bitshares like months to a flame. I think Ethereum's approach of attracting talent/interest is different then ours. Ethereum has a star power for sure, just read through the list of names of people working on the project. That in itself is huge. Bitshares has maybe some less established players but arguably twice as hungry. These guys don't have long legacy's of accolades, most of their stories good or bad have yet to be written.  I don't know so I will ask, Why does it  seem like  Ethereum has attracted the attention of many of the established players while Bitshares developers seem to be younger and with less......history? I think the answer has alot to do with you and as stated above, your ability to attract talent.Which you have a proven track record of.

Bitshares attracts talent through incentive(delegates) and by appealing to ideal's, Does Ethereum just appeal to ideal's to attract talent?


"It seems to be a payment mechanism for work and that's great to explore. The bigger issue is if the development team is inclusive or exclusive. Bitcoin is terribly closed to the outside world and many with great ideas from Amir Taaki to the Btcd project have been excluded from the conversation for whatever reason is floating in the core developer's head.

I think it's worth spending some time examining successful open source projects like the linux project (800 developers from 100 countries) to firefox. What have they done to attract talent and new ideas? How do they manage the community? How do they deal with different philosophies and goals? A little bit of time in reflection can yield great results. "


Your comparisons are to preemptive to draw any kind of conclusions. The projects stated above long histories. Firefox was started by 2 people who worked together that were unhappy about the direction their boss was telling them to go.They were also done at a time when the internet was young. In order to understand why some one thinks or feels the way they do you must not only look at the person or company but you must also look at the time period they worked in.

To quote BM "Bitshares is like a onion, Bitshares has layers". To me Bitcoin(god bless it, if you believe in that kind of thing) is a victim of its own success. Money attracts alot of player's and each player with their own agenda. We are only at the outer most layer. We are just learning how people will behave as delegates and how voters will use their power. Thats not even taking the challenges that the code itself into consideration. 

Bitshares has caught alot of flack because of the way it has changed or even better evolved. I won't argue if the changes are good or bad from the original, thats for nature to decide.I will argue that its willingness to make big moves and bold changes will help keep the project a success.

I wish you would consider joining a mumble session. A good portion of this conversation is about the free exchange of thoughts and ideas, why not come share some with us. Not only that but I think you would probably make a certain fuzz a very happy happy guy. 



 

[charleshoskinson]

No Charles, I'm not involved with BitShares software development.

I agree with you that a stronger review process than is currently in place now would be an important addition at some point (assuming the team uses an in-house peer review process of some sort now), but it's not clear to me the time is right for it.

A person with the skills to do the work you suggest probably won't come cheap, and it would certainly slow down momentum. It also may be difficult to insert such a person into the culture of the team.

I think we need to be very careful about mucking around with the internal process of BitShares software development. We want to be informed about status and progress and being inquisitive about it is certainly a good thing, but we also need to recognize we're not involved closely enough to make decisions that could dramatically change how the dev team functions.

We should trust those in a better position to make such calls. It's not blind trust, the dev team and their leaders have demonstrated excellent progress and generally good decisions. And as shareholders we are provided a much higher degree of access to the team, far more than all other crypto projects I know of.

Good ideas are being raised in this thread. All I'm saying is that our suggestions should be tempered by our limited, outside perspective. I'm guessing but I suspect the majority of the stakeholders do not have much if any experience in the software field.

Being on the inside and then on the outside, I suppose I have a different perspective. So far 4 million dollars has been spent and there isn't a stable client nor a clear development roadmap and testing process. I don't believe the current team is using a methodology like scrum nor have I seen any clear documentation on core pieces of technology like the consensus algorithm, titan, how the crypto is implemented, etc. Furthermore, there seems to be a family of projects all leveraging the same codebase, but I'm unclear on the relationships between them and also how this impacts developer resources.

To me rich documentation is incredibly important to all open source projects. For example, look at api.jquery.com or zeromq http://zeromq.org/intro:read-the-manual, which I consider to be very well run projects off of a pretty minimal budget. Second, there has to be a framework for how outside developers can understand the project, its goals, and how to participate. Bitcoin has BIPs that yield a great degree of controversy, yet they still have a system for proposing and specifying new features and functionality. I'm not aware of anything like this from the bitshares team. 

In the long term I agree the above would be great but In order to attract the great minds you are suggesting you need money/adoption/notoriety

The project raised over 4 million throughout its history and I was able to get Koblitz and Merkle to join ethereum prior to even a fraction of that funding. I think that good projects are able to attract great minds if the ideas are accessible and there is an emphasis placed upon collaboration. Vitalik established a wonderfully collaborative environment for people to join Ethereum, do you feel the same has been done for the developers behind bitshares?

It funny when you think about it. You have to push ahead at almost reckless speed in order to get to the point of attracting the above minds,go to slow and you become irrelevant before your ideas hit the market. The entire time trying to hang on and not make to many mistakes along the way.I don't think it has to be one coin/token/asset to rule them all but I do think their are limited spots available.

I think devshares are going to be a important part of the above process. A real playground/proving ground for devs and user's. I don't think its the complete answer but a piece of it that may help us avoid the biggest of mistakes.

What are your thoughts on devshares and how they may fit in?

It seems to be a payment mechanism for work and that's great to explore. The bigger issue is if the development team is inclusive or exclusive. Bitcoin is terribly closed to the outside world and many with great ideas from Amir Taaki to the Btcd project have been excluded from the conversation for whatever reason is floating in the core developer's head.

I think it's worth spending some time examining successful open source projects like the linux project (800 developers from 100 countries) to firefox. What have they done to attract talent and new ideas? How do they manage the community? How do they deal with different philosophies and goals? A little bit of time in reflection can yield great results.

---

[Gentso1]

If a DPOS based system is going to succeed it

The bigger issue is that DPOS itself needs to be vetted by some people with a strong cryptography and computer science background. Stellar for example discovered some flaws in their consensus algorithm. It's tough to design and deploy these things and the eventual implementation may be riddled with suboptimal design choices. Bitshares really needs a chief cryptographer to vet both the code and the consensus algo.

You guys also need a quality assurance delegate to review the coding practices, project management, and developer productivity and then write objective reports on some regular basis for the voters to review.

In the long term I agree the above would be great but In order to attract the great minds you are suggesting you need money/adoption/notoriety . It funny when you think about it. You have to push ahead at almost reckless speed in order to get to the point of attracting the above minds,go to slow and you become irrelevant before your ideas hit the market. The entire time trying to hang on and not make to many mistakes along the way.I don't think it has to be one coin/token/asset to rule them all but I do think their are limited spots available.

I think devshares are going to be a important part of the above process. A real playground/proving ground for devs and user's. I don't think its the complete answer but a piece of it that may help us avoid the biggest of mistakes.

What are your thoughts on devshares and how they may fit in?

[Thom]

Thom are you involved in writing the code or QA for bitshares?

No Charles, I'm not involved with BitShares software development.

I agree with you that a stronger review process than is currently in place now would be an important addition at some point (assuming the team uses an in-house peer review process of some sort now), but it's not clear to me the time is right for it.

A person with the skills to do the work you suggest probably won't come cheap, and it would certainly slow down momentum. It also may be difficult to insert such a person into the culture of the team.

I think we need to be very careful about mucking around with the internal process of BitShares software development. We want to be informed about status and progress and being inquisitive about it is certainly a good thing, but we also need to recognize we're not involved closely enough to make decisions that could dramatically change how the dev team functions.

We should trust those in a better position to make such calls. It's not blind trust, the dev team and their leaders have demonstrated excellent progress and generally good decisions. And as shareholders we are provided a much higher degree of access to the team, far more than all other crypto projects I know of.

Good ideas are being raised in this thread. All I'm saying is that our suggestions should be tempered by our limited, outside perspective. I'm guessing but I suspect the majority of the stakeholders do not have much if any experience in the software field.

[werneo]

If a DPOS based system is going to succeed it

The bigger issue is that DPOS itself needs to be vetted by some people with a strong cryptography and computer science background. Stellar for example discovered some flaws in their consensus algorithm. It's tough to design and deploy these things and the eventual implementation may be riddled with suboptimal design choices. Bitshares really needs a chief cryptographer to vet both the code and the consensus algo.

You guys also need a quality assurance delegate to review the coding practices, project management, and developer productivity and then write objective reports on some regular basis for the voters to review.

YES

 

[charleshoskinson]

If a DPOS based system is going to succeed it

The bigger issue is that DPOS itself needs to be vetted by some people with a strong cryptography and computer science background. Stellar for example discovered some flaws in their consensus algorithm. It's tough to design and deploy these things and the eventual implementation may be riddled with suboptimal design choices. Bitshares really needs a chief cryptographer to vet both the code and the consensus algo.

You guys also need a quality assurance delegate to review the coding practices, project management, and developer productivity and then write objective reports on some regular basis for the voters to review.

[Gentso1]

Thanks so much for everyone's posts and points of view. It looks like I have a video to watch and a little reading.

Your insight's as coders help people like me to think about and understand the work you are able to and also how efficiently you are able to do it.If a DPOS based system is going to succeed it

depends on shareholders voting and understanding what they are voting on, I think I can do the later a little bit easier now.

 

[charleshoskinson]

Thom are you involved in writing the code or QA for bitshares?

[Thom]

That was a good overview of the important aspects Charles, quite thorough without being so detailed you have to have a degree in computer science or be a developer to understand the important aspects of software development.

Gamey also made a good point about how arduous tracking down bugs can be and how tracking commit activity can be a very poor metric to gauge a developer's contributions.

Having been a developer for several decades myself I can testify how important the dev process is, as well as the funding and attitude about quality control, what methods of code review are used, the level of unit testing required at various stages of the coding cycle, and how bug tracking is utilized. I also believe it's important to rotate members of the dev team in and out of the various roles. In my experience devs generally prefer to work on new code / functionality as opposed to bug fixing or writing test suites.

There are many things to consider that few people can appreciate if they've never been a developer.

[onceuponatime]

Here is a course I'd recommend to get a better understanding how how a version control system works: https://www.udacity.com/course/viewer#!/c-ud775/l-2980038599. It's not terribly difficult to understand from a high level. Basically, software developers are working on the same application on different machines and at different times and locations. In a perfect world, each would have their own little module they are responsible for and no one else would ever touch their code.

Of course, this isn't the case, development is a collaborative, often messy process with many different eyes and hands touching the same source and at different times. Thus one needs what is called a version control system to sort out who has done what and when and also to create living history so that one can rewind the clock to earlier periods in the project's history.

Often one can look at commits as a metric of developer productivity telling you in a transparent log when, how often and what a developer has done. Git is a decentralized software system to sort all of this out. Github is a website that allows people to store and audit their code online and is free to use for open source projects. There are many types of VCS and lots of philosophy on how to use them and what is best for a particular type of project. I'd recommend looking at this wiki: http://en.wikipedia.org/wiki/Revision_control for the terminology that is commonly used and also this wiki for list of different VCS -> http://en.wikipedia.org/wiki/List_of_revision_control_software.

I hope that helps

It helps! Thank you.

[charleshoskinson]

Here is a course I'd recommend to get a better understanding how how a version control system works: https://www.udacity.com/course/viewer#!/c-ud775/l-2980038599. It's not terribly difficult to understand from a high level. Basically, software developers are working on the same application on different machines and at different times and locations. In a perfect world, each would have their own little module they are responsible for and no one else would ever touch their code.

Of course, this isn't the case, development is a collaborative, often messy process with many different eyes and hands touching the same source and at different times. Thus one needs what is called a version control system to sort out who has done what and when and also to create living history so that one can rewind the clock to earlier periods in the project's history.

Often one can look at commits as a metric of developer productivity telling you in a transparent log when, how often and what a developer has done. Git is a decentralized software system to sort all of this out. Github is a website that allows people to store and audit their code online and is free to use for open source projects. There are many types of VCS and lots of philosophy on how to use them and what is best for a particular type of project. I'd recommend looking at this wiki: http://en.wikipedia.org/wiki/Revision_control for the terminology that is commonly used and also this wiki for list of different VCS -> http://en.wikipedia.org/wiki/List_of_revision_control_software.

I hope that helps

Any suggestions of what other holders like myself can use to help to gauge what  coder is doing. I know this is a tough question, I am just looking for some guidelines.

Without having knowledge about the language they are coding in or the fundamentals covering the problems they are trying to solve, this is tough. Generally you can look at documentation associated with commits, code comments, check style and format of the code via some validator like pylint. Also you can ask questions about quality control and testing. For example, where are the unit tests. How did you determine that once merged this code wouldn't break the system? Peer review is also a valid way of determining quality. There are development systems like behavior driven development and methodologies like Scrum that help make the process smoother and more auditable to outside parties.

The reality is that the environment in which the code is written and the project management has as much to do with the end result as the skill of the developer. Bad processes can slow or destroy progress and force bad architecture to be maintained. Also there is a broader meta question of what do we want this program to work with and on? The decisions made there can dramatically impact speed quality, security and usability. Generally the person responsible for those decisions has a role like chief software architect.

[Gentso1]

Please understand I get that its not just about commits. I am trying to get my own personal set of metrics.

With devs coming onto the forum needing to have delegates elected I think its important for shareholders to be at least somewhat educated on who is doing what and how often.

I think I have a basic understanding of commits now.

Any suggestions of what other holders like myself can use to help to gauge what  coder is doing. I know this is a tough question, I am just looking for some guidelines.


Security of shares and education of holders is the first step to a greater voter participation imho.

[gamey]

Even if you get past commits and into # of code line changes it would be something of an improvement.  However, you would be skipping over people who might not be coding and instead tracking down hard to find bugs.  Debugging obscure bugs is the type of thing that can take a week and lead to 1 line of code change.  It is a job that is just as key as writing the code itself, arguably more key.

So.. please don't read too much into commits.

[Thom]

More specifically, frequency of commits gives you an idea of whether someone is actively working on something or not.  No commits means they are not writing code.

In theory a developer should commit their work on a daily basis even if it is incomplete.  In practice any developer that goes weeks between commits is likely doing something else other than coding.

The specific definition for a github (or other source code management systems) commit is: A "commit" is the action performed by a developer to contribute or commit code to the source repository. As toast says it is only a rough gauge of activity. A simple spelling error in a code comment could be fixed and committed and that increments the version / commit number, tho it had zero effect on the functionality of the code.

To somewhat counter to BM's first sentence, it is possible a developer is actually doing coding work but hasn't checked in (committed) changes yet. As BM went on to explain, following good coding practices would mean regular commits, generally a minimum of once per day. However, there are a number of reasons the frequency might legitimately less than once per day. It really depends on the urgency of the changes, whether the programmer might be doing work while on the road or whether the code is for a brand new feature and has no other dependencies and is a prototype / work in progress / experiment.

The point is there are exceptions to the a daily commit schedule. In general it should be done quite often. It reduces the risk of loosing changes and provides a very important control point, especially where many developers are working on the same project. When it comes to open source projects like BitShares it's important to keep everyone syncronized and on the same page so to speak.

[bytemaster]

More specifically, frequency of commits gives you an idea of whether someone is actively working on something or not.  No commits means they are not writing code.

In theory a developer should commit their work on a daily basis even if it is incomplete.  In practice any developer that goes weeks between commits is likely doing something else other than coding. 

[toast]

In theory a commit is the smallest unit of code change.

Commits are as bad of a metric as lines of code. They give you a very rough sense of activity, but rewarding based on either will lead to badly broken incentives.

[Gentso1]

If you google the above term it gives you answers based on you trying to learn to use github.

I have no interest in that. I am trying to get a working understanding of what commits actually are and more importantly if we as users/shareholders can use them as some sort of metric.I would ideally

like to be able to have a rough gauge of what devs are working on and how often. I can see part of this (I think) by looking at the branch the commit is going to.

With Dev's now having to come onto the forum and make a case for their delegates this could make their job easier if folks like me understand Github.

Any thoughts or ideas on bridging the Dev/shareholder divide would be greatly appreciated.