Topic: Software Development Team RFP

Camp: Agreement

Camp Statement History

Objected
Live
In Review
Old
Statement :

Software Development Team Request For Proposal


Canonizer seeks to contract with a software development team of 4 or 5 full time engineers to help convert the current prototype system at Canonizer.com to an open source, fully developed, fully automatically tested and deployable product that can scale to handle millions of simultaneous users. We need a team that can continue the development of the open source Canonizer.2.0 system, currently using LAMPS with the Laravel framework.

Canonizer plans to become the Wikipedia of thought and opinion on controversial issues. We are going to bring the world together by building and tracking consensus on moral topics.

As you prepare your proposals please consider the following:
  1. Currently the system is running on a single AWS EC2 instance. This can only handle a small number of users at a time without significant performance degradation. A system needs to be designed that enables the system to expand to new instances, and contract, as needed to handle any load.
  2. Help us re-architect and help implement and convert to a new text editing and management system module. The current wiki markup is cumbersome with inconsistent formatting. “Ease of use” being of utmost importance, so UI design abilities are important. This includes a powerful version comparison tool to replace this does nothing version page so people can easily comprehend the diffs between version.
  3. Where possible support the open source community. If there is open source code we can leverage, let’s leverage that, possibly returning contributions to that community or else architect open source modules others can use.
  4. Help finish the design of and conversion to a fully test driven development system, with 100% automated tests and deployment to enable continuous release process.
  5. Help prioritize tasks and perform team code reviews of all new development.
  6. Convert the system to a service oriented architecture, starting with the creation of a new “canonizer” service. This service may be built on something other than LAMPs, with cpu efficiency being of primary importance, since this will be doing most of the canonization computation. Design an API which can provide a topic num, an asof value, and a canonizer id. Given that, it will return a JSON tree structure of camps and supporters of that topic, decorated with canonized scores of the selected canonizer ids, which can then be rendered on topic pages, or called by third parties. We eventually want to provide users the ability to program their own canonizer algorithms, so a design towards making this easy for users is important.

The budget for this job will start at $100K per month or more than $1 million / year, on an ongoing basis, depending on the quality of, and amount of work being done. We intend on hiring one or more companies to help with this project, depending on expertise and abilities.

The goal of Canonizer is to be a leaderless organization where everyone knows everything. Any software development company interested in applying for this job is invited to create a sub camp, with a camp statement describing how their company is the best company for the job. Then the canonizer canonizer algorithm will be used to select the top candidate. Currently, some of the primary share holders are already supporting the Agreement Camp, where you can see their canonized share score. Eventually these supporters will be ranking their camps, in their current preferred order, which may continually change till selections are made. Candidates are also encouraged to support their own camps, as their top choice, and all competing candidates, in the order they think is the best candidate to achieve the Canonizer goal of bringing the world together.

There is a lot to learn about this canonization, consensus building process, which we hope you will learn and use to be voted and selected as the top candidate. Each camp has a “forum”, where questions can be raised. So if you have any issues our questions, everyone can go to the main Agreement Camp for the job topic, then go to the forum, and submit your questions for everyone to see. You can also solicit collaboration from other interested parties, while building consensus for the scaling design in a super camp, and so on.
Qualified teams that respond to this RFP may be eligible to receive payment for the time required to study and learn about the Canonizer process. You can reach out to support@canonizer.com and ask to meet with the primary shareholders to negotiate compensation for this development process.

You could answer at least the following questions in your camp statement:
  • How would you architect a canonizer to be massively scalable? It needs to be able to automatically grow, when needed, to handle millions of simultaneous users, then scale back to save costs when load is absent. This is particularly difficult given the real time nature of the canonizer process used to display each topic, currently being done in real time, part of why the system is slow. Each time a topic is displayed, you need to iterate on each camp C * iterate on each supporter S * perform the canonizer algorithm for each person A * for some topics repeat this entire process on yet another topic, resulting in a current speed of C * S * A partial (C * S * A) all given any “as of” date either current or at any time in the past. For more information see this “ peer ranked” canonizer algorithm information.
    • You will get extra credit if you collaborate with others competing for this position to build consensus around and collaboratively develop a design, possibly creating a supper camp multiple competing camps can support, showing your support for that scalable software design as it is being collaboratively developed. If you are late to the game, and others competing for this position have already developed and are supporting a good design, you may just choose to move your camp into a supporting sub camp position of that design, indicating you think it is the best design. Of course, any additional contribution to improve any existing design camp will be to your credit. And if there are any existing proposals for which you disagree are the best, you can start a new supporting sub camp with the proposal you think is better.
  • What type of team management or prioritization tools are normally used, if any?
  • What is your philosophy on code reviews by team members, or strategies such as team or pair coding?
  • What experience do you have setting up and maintaining systems that are 100% continuous delivery enabled, including automated tests that prove 100% of functionality still works with each modification made to the code, along with automatic deployment of such fully tested changes
  • Provide any other ideas of how you could contribute or help improve Canonizer and it’s goals.
  • Do you have any examples of times when you went beyond what was being asked of you by your immediate supervisor to further the goals of the company or humanity as a whole?
This recruiting process is expected to take multiple months to find the best company. We are a global team so it doesn’t matter where in the world the engineers are located, we only ask that you be flexible with meeting or daily standup times.

To Do List

Sunny Jindale, with Iffort, proposed putting out some tasks that teams could get started on. So here are a few possibilities:
  1. Specify a JSON structure, which the canonizer service mentioned above will return. If 3rd parties want this data, they should be able to call this service directly, so they don’t need to request an html topic page, then parse the HTML to get the data. We of course will eventually want to remove any existing code in the system that gets this data from the MySQL database, and convert it to also use this same service. There would need to be a standard javascript function to convert this json to a javascript structure (linked both up and down the tree) that can easily be traversed to render html on a topic/camp page, either on client or server side. Also specify what type of system would be used to compute this as efficiently as possible compute and db access wise, if something other than laravel/php. For example, would Amazon's Lambda system work efficiently for this? Keep in mind that in the future this json structure is what may be cashed, and when we have hundreds of thousands of supporters of camps in a single topic, we may want to only get part of the tree, and not request subsets of the data till the user asks to expand that node in the tree, and so on.
  2. Potential Security Vulnerabilities being reported in Github. As you can see from this link, Github is reporting this issue. Our engineers have started considering the work required to update our system to current library versions, in order to get these issues fixed, but we haven’t yet had the time required to get this high priority issue resolved, yet.
  3. There is a boat load of open issues for that repository. If you see one on that list that you’d like to tackle, that’d be great. Just let us know which one you’d like to get started on, so we can make sure someone isn’t already working on that one. The ones with the “21st Release” tag are being currently worked on for the next release.
There are instructions on how to set up and build a development version of Canonizer in the project’s main README.md file.

Edit summary : Add a new item on the Things To Do list. Specify the JSON tree structure of camps and supporters which the canonizer service will return.
Submitted on :
Submitter Nick Name : Brent_Allsop
Go live Time :
Statement :

Software Development Team Request For Proposal


Canonizer seeks to contract with a software development team of 4 or 5 full time engineers to help convert the current prototype system at Canonizer.com to an open source, fully developed, fully automatically tested and deployable product that can scale to handle millions of simultaneous users. We need a team that can continue the development of the open source Canonizer.2.0 system, currently using LAMPS with the Laravel framework.

Canonizer plans to become the Wikipedia of thought and opinion on controversial issues. We are going to bring the world together by building and tracking consensus on moral topics.

As you prepare your proposals please consider the following:
  1. Currently the system is running on a single AWS EC2 instance. This can only handle a small number of users at a time without significant performance degradation. A system needs to be designed that enables the system to expand to new instances, and contract, as needed to handle any load.
  2. Help us re-architect and help implement and convert to a new text editing and management system module. The current wiki markup is cumbersome with inconsistent formatting. “Ease of use” being of utmost importance, so UI design abilities are important. This includes a powerful version comparison tool to replace this does nothing version page so people can easily comprehend the diffs between version.
  3. Where possible support the open source community. If there is open source code we can leverage, let’s leverage that, possibly returning contributions to that community or else architect open source modules others can use.
  4. Help finish the design of and conversion to a fully test driven development system, with 100% automated tests and deployment to enable continuous release process.
  5. Help prioritize tasks and perform team code reviews of all new development.
  6. Convert the system to a service oriented architecture, starting with the creation of a new “canonizer” service. This service may be built on something other than LAMPs, with cpu efficiency being of primary importance, since this will be doing most of the canonization computation. Design an API which can provide a topic num, an asof value, and a canonizer id. Given that, it will return a JSON tree structure of camps and supporters of that topic, decorated with canonized scores of the selected canonizer ids, which can then be rendered on topic pages, or called by third parties. We eventually want to provide users the ability to program their own canonizer algorithms, so a design towards making this easy for users is important.

The budget for this job will start at $100K per month or more than $1 million / year, on an ongoing basis, depending on the quality of, and amount of work being done. We intend on hiring one or more companies to help with this project, depending on expertise and abilities.

The goal of Canonizer is to be a leaderless organization where everyone knows everything. Any software development company interested in applying for this job is invited to create a sub camp, with a camp statement describing how their company is the best company for the job. Then the canonizer canonizer algorithm will be used to select the top candidate. Currently, some of the primary share holders are already supporting the Agreement Camp, where you can see their canonized share score. Eventually these supporters will be ranking their camps, in their current preferred order, which may continually change till selections are made. Candidates are also encouraged to support their own camps, as their top choice, and all competing candidates, in the order they think is the best candidate to achieve the Canonizer goal of bringing the world together.

There is a lot to learn about this canonization, consensus building process, which we hope you will learn and use to be voted and selected as the top candidate. Each camp has a “forum”, where questions can be raised. So if you have any issues our questions, everyone can go to the main Agreement Camp for the job topic, then go to the forum, and submit your questions for everyone to see. You can also solicit collaboration from other interested parties, while building consensus for the scaling design in a super camp, and so on.
Qualified teams that respond to this RFP may be eligible to receive payment for the time required to study and learn about the Canonizer process. You can reach out to support@canonizer.com and ask to meet with the primary shareholders to negotiate compensation for this development process.

You could answer at least the following questions in your camp statement:
  • How would you architect a canonizer to be massively scalable? It needs to be able to automatically grow, when needed, to handle millions of simultaneous users, then scale back to save costs when load is absent. This is particularly difficult given the real time nature of the canonizer process used to display each topic, currently being done in real time, part of why the system is slow. Each time a topic is displayed, you need to iterate on each camp C * iterate on each supporter S * perform the canonizer algorithm for each person A * for some topics repeat this entire process on yet another topic, resulting in a current speed of C * S * A partial (C * S * A) all given any “as of” date either current or at any time in the past. For more information see this “ peer ranked” canonizer algorithm information.
    • You will get extra credit if you collaborate with others competing for this position to build consensus around and collaboratively develop a design, possibly creating a supper camp multiple competing camps can support, showing your support for that scalable software design as it is being collaboratively developed. If you are late to the game, and others competing for this position have already developed and are supporting a good design, you may just choose to move your camp into a supporting sub camp position of that design, indicating you think it is the best design. Of course, any additional contribution to improve any existing design camp will be to your credit. And if there are any existing proposals for which you disagree are the best, you can start a new supporting sub camp with the proposal you think is better.
  • What type of team management or prioritization tools are normally used, if any?
  • What is your philosophy on code reviews by team members, or strategies such as team or pair coding?
  • What experience do you have setting up and maintaining systems that are 100% continuous delivery enabled, including automated tests that prove 100% of functionality still works with each modification made to the code, along with automatic deployment of such fully tested changes
  • Provide any other ideas of how you could contribute or help improve Canonizer and it’s goals.
  • Do you have any examples of times when you went beyond what was being asked of you by your immediate supervisor to further the goals of the company or humanity as a whole?
This recruiting process is expected to take multiple months to find the best company. We are a global team so it doesn’t matter where in the world the engineers are located, we only ask that you be flexible with meeting or daily standup times.

To Do List

Sunny Jindale, with Iffort, proposed putting out some tasks that teams could get started on. So here are a few possibilities:
  1. Potential Security Vulnerabilities being reported in Github. As you can see from this link, Github is reporting this issue. Our engineers have started considering the work required to update our system to current library versions, in order to get these issues fixed, but we haven’t yet had the time required to get this high priority issue resolved, yet.
  2. There is a boat load of open issues for that repository. If you see one on that list that you’d like to tackle, that’d be great. Just let us know which one you’d like to get started on, so we can make sure someone isn’t already working on that one. The ones with the “21st Release” tag are being currently worked on for the next release.
There are instructions on how to set up and build a development version of Canonizer in the project’s main README.md file.

Edit summary : Add "To Do" list of possible things teams may want to get started on.
Submitted on :
Submitter Nick Name : Brent_Allsop
Go live Time :
Statement :

Software Development Team Request For Proposal


Canonizer seeks to contract with a software development team of 4 or 5 full time engineers to help convert the current prototype system at Canonizer.com to an open source, fully developed, fully automatically tested and deployable product that can scale to handle millions of simultaneous users. We need a team that can continue the development of the open source Canonizer.2.0 system, currently using LAMPS with the Laravel framework.

Canonizer plans to become the Wikipedia of thought and opinion on controversial issues. We are going to bring the world together by building and tracking consensus on moral topics.

As you prepare your proposals please consider the following:
  1. Currently the system is running on a single AWS EC2 instance. This can only handle a small number of users at a time without significant performance degradation. A system needs to be designed that enables the system to expand to new instances, and contract, as needed to handle any load.
  2. Help us re-architect and help implement and convert to a new text editing and management system module. The current wiki markup is cumbersome with inconsistent formatting. “Ease of use” being of utmost importance, so UI design abilities are important. This includes a powerful version comparison tool to replace this does nothing version page so people can easily comprehend the diffs between version.
  3. Where possible support the open source community. If there is open source code we can leverage, let’s leverage that, possibly returning contributions to that community or else architect open source modules others can use.
  4. Help finish the design of and conversion to a fully test driven development system, with 100% automated tests and deployment to enable continuous release process.
  5. Help prioritize tasks and perform team code reviews of all new development.
  6. Convert the system to a service oriented architecture, starting with the creation of a new “canonizer” service. This service may be built on something other than LAMPs, with cpu efficiency being of primary importance, since this will be doing most of the canonization computation. Design an API which can provide a topic num, an asof value, and a canonizer id. Given that, it will return a JSON tree structure of camps and supporters of that topic, decorated with canonized scores of the selected canonizer ids, which can then be rendered on topic pages, or called by third parties. We eventually want to provide users the ability to program their own canonizer algorithms, so a design towards making this easy for users is important.

The budget for this job will start at $100K per month or more than $1 million / year, on an ongoing basis, depending on the quality of, and amount of work being done. We intend on hiring one or more companies to help with this project, depending on expertise and abilities.

The goal of Canonizer is to be a leaderless organization where everyone knows everything. Any software development company interested in applying for this job is invited to create a sub camp, with a camp statement describing how their company is the best company for the job. Then the canonizer canonizer algorithm will be used to select the top candidate. Currently, some of the primary share holders are already supporting the Agreement Camp, where you can see their canonized share score. Eventually these supporters will be ranking their camps, in their current preferred order, which may continually change till selections are made. Candidates are also encouraged to support their own camps, as their top choice, and all competing candidates, in the order they think is the best candidate to achieve the Canonizer goal of bringing the world together.

There is a lot to learn about this canonization, consensus building process, which we hope you will learn and use to be voted and selected as the top candidate. Each camp has a “forum”, where questions can be raised. So if you have any issues our questions, everyone can go to the main Agreement Camp for the job topic, then go to the forum, and submit your questions for everyone to see. You can also solicit collaboration from other interested parties, while building consensus for the scaling design in a super camp, and so on.
Qualified teams that respond to this RFP may be eligible to receive payment for the time required to study and learn about the Canonizer process. You can reach out to support@canonizer.com and ask to meet with the primary shareholders to negotiate compensation for this development process.

You could answer at least the following questions in your camp statement:
  • How would you architect a canonizer to be massively scalable? It needs to be able to automatically grow, when needed, to handle millions of simultaneous users, then scale back to save costs when load is absent. This is particularly difficult given the real time nature of the canonizer process used to display each topic, currently being done in real time, part of why the system is slow. Each time a topic is displayed, you need to iterate on each camp C * iterate on each supporter S * perform the canonizer algorithm for each person A * for some topics repeat this entire process on yet another topic, resulting in a current speed of C * S * A partial (C * S * A) all given any “as of” date either current or at any time in the past. For more information see this “ peer ranked” canonizer algorithm information.
    • You will get extra credit if you collaborate with others competing for this position to build consensus around and collaboratively develop a design, possibly creating a supper camp multiple competing camps can support, showing your support for that scalable software design as it is being collaboratively developed. If you are late to the game, and others competing for this position have already developed and are supporting a good design, you may just choose to move your camp into a supporting sub camp position of that design, indicating you think it is the best design. Of course, any additional contribution to improve any existing design camp will be to your credit. And if there are any existing proposals for which you disagree are the best, you can start a new supporting sub camp with the proposal you think is better.
  • What type of team management or prioritization tools are normally used, if any?
  • What is your philosophy on code reviews by team members, or strategies such as team or pair coding?
  • What experience do you have setting up and maintaining systems that are 100% continuous delivery enabled, including automated tests that prove 100% of functionality still works with each modification made to the code, along with automatic deployment of such fully tested changes
  • Provide any other ideas of how you could contribute or help improve Canonizer and it’s goals.
  • Do you have any examples of times when you went beyond what was being asked of you by your immediate supervisor to further the goals of the company or humanity as a whole?
This recruiting process is expected to take multiple months to find the best company. We are a global team so it doesn’t matter where in the world the engineers are located, we only ask that you be flexible with meeting or daily standup times.

Edit summary : Be more precise with the budget starting at $100K / month.
Submitted on :
Submitter Nick Name : Brent_Allsop
Go live Time :
Statement :

Software Development Team Request For Proposal


Canonizer seeks to contract with a software development team of 4 or 5 full time engineers to help convert the current prototype system at Canonizer.com to an open source, fully developed, fully automatically tested and deployable product that can scale to handle millions of simultaneous users. We need a team that can continue the development of the open source Canonizer.2.0 system, currently using LAMPS with the Laravel framework.

Canonizer plans to become the Wikipedia of thought and opinion on controversial issues. We are going to bring the world together by building and tracking consensus on moral topics.

As you prepare your proposals please consider the following:

  1. Currently the system is running on a single AWS EC2 instance. This can only handle a small number of users at a time without significant performance degradation. A system needs to be designed that enables the system to expand to new instances, and contract, as needed to handle any load.
  2. Help us re-architect and help implement and convert to a new text editing and management system module. The current wiki markup is cumbersome with inconsistent formatting. “Ease of use” being of utmost importance, so UI design abilities are important. This includes a powerful version comparison tool to replace this does nothing version page so people can easily comprehend the diffs between version.
  3. Where possible support the open source community. If there is open source code we can leverage, let’s leverage that, possibly returning contributions to that community or else architect open source modules others can use.
  4. Help finish the design of and conversion to a fully test driven development system, with 100% automated tests and deployment to enable continuous release process.
  5. Help prioritize tasks and perform team code reviews of all new development.
  6. Convert the system to a service oriented architecture, starting with the creation of a new “canonizer” service. This service may be built on something other than LAMPs, with cpu efficiency being of primary importance, since this will be doing most of the canonization computation. Design an API which can provide a topic num, an asof value, and a canonizer id. Given that, it will return a JSON tree structure of camps and supporters of that topic, decorated with canonized scores of the selected canonizer ids, which can then be rendered on topic pages, or called by third parties. We eventually want to provide users the ability to program their own canonizer algorithms, so a design towards making this easy for users is important.

The budget for this job could be as much as $1 million / year, on an ongoing basis, depending on the quality of, and amount of work being done. We intend on hiring one or more companies to help with this project, depending on expertise and abilities.
The goal of Canonizer is to be a leaderless organization where everyone knows everything. Any software development company interested in applying for this job is invited to create a sub camp, with a camp statement describing how their company is the best company for the job. Then the canonizer canonizer algorithm will be used to select the top candidate. Currently, some of the primary share holders are already supporting the Agreement Camp, where you can see their canonized share score. Eventually these supporters will be ranking their camps, in their current preferred order, which may continually change till selections are made. Candidates are also encouraged to support their own camps, as their top choice, and all competing candidates, in the order they think is the best candidate to achieve the Canonizer goal of bringing the world together.
There is a lot to learn about this canonization, consensus building process, which we hope you will learn and use to be voted and selected as the top candidate. Each camp has a “forum”, where questions can be raised. So if you have any issues our questions, everyone can go to the main Agreement Camp for the job topic, then go to the forum, and submit your questions for everyone to see. You can also solicit collaboration from other interested parties, while building consensus for the scaling design in a super camp, and so on.
Qualified teams that respond to this RFP may be eligible to receive payment for the time required to study and learn about the Canonizer process. You can reach out to support@canonizer.com and ask to meet with the primary shareholders to negotiate compensation for this development process.

You could answer at least the following questions in your camp statement:

  • How would you architect a canonizer to be massively scalable? It needs to be able to automatically grow, when needed, to handle millions of simultaneous users, then scale back to save costs when load is absent. This is particularly difficult given the real time nature of the canonizer process used to display each topic, currently being done in real time, part of why the system is slow. Each time a topic is displayed, you need to iterate on each camp C * iterate on each supporter S * perform the canonizer algorithm for each person A * for some topics repeat this entire process on yet another topic, resulting in a current speed of C * S * A partial (C * S * A) all given any “as of” date either current or at any time in the past. For more information see this “ peer ranked” canonizer algorithm information.
    • You will get extra credit if you collaborate with others competing for this position to build consensus around and collaboratively develop a design, possibly creating a supper camp multiple competing camps can support, showing your support for that scalable software design as it is being collaboratively developed. If you are late to the game, and others competing for this position have already developed and are supporting a good design, you may just choose to move your camp into a supporting sub camp position of that design, indicating you think it is the best design. Of course, any additional contribution to improve any existing design camp will be to your credit. And if there are any existing proposals for which you disagree are the best, you can start a new supporting sub camp with the proposal you think is better.
  • What type of team management or prioritization tools are normally used, if any?
  • What is your philosophy on code reviews by team members, or strategies such as team or pair coding?
  • What experience do you have setting up and maintaining systems that are 100% continuous delivery enabled, including automated tests that prove 100% of functionality still works with each modification made to the code, along with automatic deployment of such fully tested changes
  • Provide any other ideas of how you could contribute or help improve Canonizer and it’s goals.
  • Do you have any examples of times when you went beyond what was being asked of you by your immediate supervisor to further the goals of the company or humanity as a whole?
This recruiting process is expected to take multiple months to find the best company. We are a global team so it doesn’t matter where in the world the engineers are located, we only ask that you be flexible with meeting or daily standup times.

Edit summary :
Submitted on :
Submitter Nick Name : Brent_Allsop
Go live Time :
Statement :

Chief Software Architect

or

Software as a service Firm


We need someone who can lead the canonizer software team continuing the development of the open source Canonizer.2.0 system, currently using LAMPS with the Laravel framework. Including help with the following priorities:

  1. Currently the system is running on a single AWS EC2 instance. This can only handle a small number of users at a time, without significant performance degradation. A system needs to be designed, enabling the system to expand to new instances, as needed, to handle any load. We also need to develop a way to test it to prove it is working.
  2. Re Architect and help implement and convert to a new text editing and management system module. The current wiki markup is cumbersome with inconsistent formatting. “Ease of use” being of utmost importance, so UI design abilities are important.
  3. Where possible support the open source community. If there is open source code we can use, let’s leverage that, or else architect modules others can use.
  4. Help finish the design of and conversion to a fully test driven development system, with 100% automated tests and deployment to enable continuous release process.
  5. Help prioritize tasks and perform team code reviews of all new development.
  6. Convert the system to a service oriented architecture, starting with the creation of a new “canonizer” service. This service may be built on something other than LAMPs, with cpu efficiency being of primary importance. Design an API which can provide a topic num, an asof value, and a canonizer id. Given that, it will return a JSON tree structure of camps and supporters of that topic, decorated with canonized scores of the selected canonizer ids, which can then be rendered on topic pages, or called by third parties. We eventually want to provide users the ability to program their own canonizer algorithms, so a design towards making this easy for users is important.
The goal of Canonizer is to be a leaderless organization where everyone knows everything. Anyone interested in applying for this job is invited to create a sub camp, with a camp statement describing how they are the best person for the job. Then the canonizer canonizer algorithm will be used to select the top candidate. Candidates are also encouraged to support the camps of themselves, and all competing candidates, in the order they think is the best candidate to achieve the Canonizer goal of bringing the world together.

The target salary for this job is $12000 USD / month or $144,000 USD / year, (paid in Ether if desired) depending on experience. However, if you are able to be a top performer, and willing to work for less money, indicating such in your camp statement would increase your chances of getting more people to support your camp.



You could answer at least the following questions in your camp statement:

  • How would you enable canonizer to be massively scalable? It needs to be able to automatically grow, when needed, to handle millions of simultaneous users, then scale back to save costs when load is absent?
    • You will get extra credit if you collaborate with others competing for this position to build consensus around and collaboratively develop a design, possibly creating a supper camp multiple competing camps can support, showing your support for that scalable software design as it is being collaboratively developed. If you are late to the game, and others competing for this position have already developed and are supporting a good design, you may just choose to move your camp into a supporting sub camp position of that design, indicating you think it is the best design. Of course, any additional contribution to improve any existing design camp will be to your credit.
  • What type of team management or prioritization tools do you like to use, if any?
  • What is your philosophy on code reviews by team members, or strategies such as team or pair coding?
  • What experience do you have setting up and maintaining systems that are 100% continuous delivery enabled, including automated tests that prove 100% of functionality still works with each modification made to the code, along with automatic deployment of such fully tested changes
    • What were the most difficult parts of setting up and maintaining such a continuous delivery system, and how were these issues addressed?
  • Provide any other ideas of how you could contribute or help improve Canonizer and it’s goals.
  • Do you have any examples of times when you went beyond what was being asked of you by your immediate supervisor to further the goals of the company or humanity as a whole?
This recruiting process is expected to take multiple months to find the best person. We are a global team so it doesn’t matter where in the world you are located, we only ask that you be flexible with meeting times.

Edit summary : add Software as a service Frim
Submitted on :
Submitter Nick Name : Brent_Allsop
Go live Time :
Statement :

Chief Software Architect


We need someone who can lead the canonizer software team continuing the development of the open source Canonizer.2.0 system, currently using LAMPS with the Laravel framework. Including help with the following priorities:

  1. Currently the system is running on a single AWS EC2 instance. This can only handle a small number of users at a time, without significant performance degradation. A system needs to be designed, enabling the system to expand to new instances, as needed, to handle any load. We also need to develop a way to test it to prove it is working.
  2. Re Architect and help implement and convert to a new text editing and management system module. The current wiki markup is cumbersome with inconsistent formatting. “Ease of use” being of utmost importance, so UI design abilities are important.
  3. Where possible support the open source community. If there is open source code we can use, let’s leverage that, or else architect modules others can use.
  4. Help finish the design of and conversion to a fully test driven development system, with 100% automated tests and deployment to enable continuous release process.
  5. Help prioritize tasks and perform team code reviews of all new development.
  6. Convert the system to a service oriented architecture, starting with the creation of a new “canonizer” service. This service may be built on something other than LAMPs, with cpu efficiency being of primary importance. Design an API which can provide a topic num, an asof value, and a canonizer id. Given that, it will return a JSON tree structure of camps and supporters of that topic, decorated with canonized scores of the selected canonizer ids, which can then be rendered on topic pages, or called by third parties. We eventually want to provide users the ability to program their own canonizer algorithms, so a design towards making this easy for users is important.
The goal of Canonizer is to be a leaderless organization where everyone knows everything. Anyone interested in applying for this job is invited to create a sub camp, with a camp statement describing how they are the best person for the job. Then the canonizer canonizer algorithm will be used to select the top candidate. Candidates are also encouraged to support the camps of themselves, and all competing candidates, in the order they think is the best candidate to achieve the Canonizer goal of bringing the world together.

The target salary for this job is $12000 USD / month or $144,000 USD / year, (paid in Ether if desired) depending on experience. However, if you are able to be a top performer, and willing to work for less money, indicating such in your camp statement would increase your chances of getting more people to support your camp.



You could answer at least the following questions in your camp statement:

  • How would you enable canonizer to be massively scalable? It needs to be able to automatically grow, when needed, to handle millions of simultaneous users, then scale back to save costs when load is absent?
    • You will get extra credit if you collaborate with others competing for this position to build consensus around and collaboratively develop a design, possibly creating a supper camp multiple competing camps can support, showing your support for that scalable software design as it is being collaboratively developed. If you are late to the game, and others competing for this position have already developed and are supporting a good design, you may just choose to move your camp into a supporting sub camp position of that design, indicating you think it is the best design. Of course, any additional contribution to improve any existing design camp will be to your credit.
  • What type of team management or prioritization tools do you like to use, if any?
  • What is your philosophy on code reviews by team members, or strategies such as team or pair coding?
  • What experience do you have setting up and maintaining systems that are 100% continuous delivery enabled, including automated tests that prove 100% of functionality still works with each modification made to the code, along with automatic deployment of such fully tested changes
    • What were the most difficult parts of setting up and maintaining such a continuous delivery system, and how were these issues addressed?
  • Provide any other ideas of how you could contribute or help improve Canonizer and it’s goals.
  • Do you have any examples of times when you went beyond what was being asked of you by your immediate supervisor to further the goals of the company or humanity as a whole?
This recruiting process is expected to take multiple months to find the best person. We are a global team so it doesn’t matter where in the world you are located, we only ask that you be flexible with meeting times.

Edit summary : Improve and move to the top, the question about collaboratively designing a scalable solution as the first question to answer.
Submitted on :
Submitter Nick Name : Brent_Allsop
Go live Time :
Statement :

Chief Software Architect


We need someone who can lead the canonizer software team continuing the development of the open source Canonizer.2.0 system, currently using LAMPS with the Laravel framework. Including help with the following priorities:
  1. Currently the system is running on a single AWS EC2 instance. This can only handle a few users at a time, without significant performance degradation. A system needs to be designed, enabling the system to expand to new instances, as needed, to handle any load. We also need to develop a way to test it to prove it is working.
  2. Re Architect and help implement and convert to a new text editing and management system module. The current wiki markup is cumbersome with inconsistent formatting. “Ease of use” being of utmost importance, so UI design abilities are important.
  3. Where possible support the open source community. If there is open source code we can use, let’s leverage that, or else architect modules others can use.
  4. Help finish the design of and conversion to a fully test driven development system, with 100% automated tests and deployment to enable continuous release process.
  5. Help prioritize tasks and perform team code reviews of all new development.
  6. Convert the system to a service oriented architecture, starting with the creation of a new “canonizer” service. This service may be built on something other than LAMPs, with cpu efficiency being of primary importance. Design an API which can provide a topic num, an asof value, and a canonizer id. Given that, it will return a JSON tree structure of camps and supporters of that topic, decorated with canonized scores of the selected canonizer ids, which can then be rendered on topic pages, or called by third parties. We eventually want to provide users the ability to program their own canonizer algorithms, so a design towards making this easy for users is important.
The goal of Canonizer is to be a leaderless organization where everyone knows everything. Anyone interested in applying for this job is invited to create a sub camp, with a camp statement describing how they are the best person for the job. Then the canonizer canonizer algorithm will be used to select the top candidate. Candidates are also encouraged to support the camps of themselves, and all competing candidates, in the order they think is the best candidate to achieve the Canonizer goal of bringing the world together.

The target salary for this job is $12000 / month or $144,000 / year, depending on experience. However, if you are able to be a top performer, and willing to work for less money, indicating such in your camp statement would increase your chances of getting more people to support your camp.



You could answer at least the following questions in your camp statement:
  • What type of team management or prioritization tools do you like to use?
  • What is your philosophy on code reviews by team members?
  • How would you design a system which could scale to millions of users?
  • What experience do you have setting up and maintaining systems that are 100% continuous delivery enabled, including automated tests that prove 100% of functionality still works with each modification made to the code, along with automatic deployment of such fully tested changes
  • What were the most difficult parts of setting up and maintaining such a continuous delivery system, and how were these issues addressed?
  • Provide any other ideas of how you could contribute or help improve the system.
This recruiting process is expected to take multiple months to find the best person. We are a global team so it doesn’t matter where in the world you are located.

Edit summary :
Submitted on :
Submitter Nick Name : Brent_Allsop
Go live Time :
Statement :
This topic is intended to be the Canonized Design of the Canonizer LLC networked node DB system.
As an example of what is needed consider the current front "top 10" page. It works while there are only 40 or so users, 20 or so topics - each with just a few POV statements on average, and each of these with only a handful of supporters. But to "canonize" this top 10 list every time someone goes to this page, each topic must be "canonized". To do this, each statement in each topic must be analyzed. To do this, each supporter of each statement must be analyzed. To do this a currently selected "Canonizer" (each user can have a different canonize configured) must be applied to each supporter which must potentially analyze many of their personal attributes and calculate a "value" according to the canoizer algorithm specified, based on these. Then it must sum these "canonized" values for all supporters, then sum these totals for all sub camp statements and apply them to each "statement", and then the structure of these statements must be sorted according to these sums. Then the top 10 of all topics must be selected to be displayed, all sorted appropriately with the "canonized" values shown for each topic and statement.
Of course, if there are thousands (Millions and more?) of topics, each with 10 (hundreds?) or so POV statements, each with potentially hundreds (some with Millions?) of supporters, with the possibility of a Canonizer that queries a large number of attributes for each supporter - the system demand, just for this top 10 splash page, if not designed properly, could grow in a terrible non linear way right? Of course, canonizeing the whole world this way, will not always be required. Canonizing an individual topic will be a much more common task. But eventually we want to be able to canonize topics with potentially millions of supporters, with an arbitrarily configured canonizer, as close to real time as possible.
We want to follow a strategy of using cheep and redundant, co-located, systems all networked together and working in a peer to peer fashion. This is so that we can throw ever more systems at the network of systems as demand grows always having more than enough so that as systems fail no one notices.
We imagine such an open and independent replicating node system set up in a way so that other companies or third parties can instantiate them on their own hardware. Such instantiations will link up into this network of Canonizer nodes, and replicate the parts of the data they would like to use for their own canonization services on their own site, in a way that contributes to the performance of the network of all Canonizer nodes in a flexible peer to peer way.
There will be non secure versions of nodes, for browsing and canonizing, that almost anyone can instantiate and link up to the network anywhere. There will be secure nodes, likely tightly controlled by Canonizer LLC in secure environments. Submissions and maintenance of information will be done on these secure nodes via SSL. Information marked private or anonymous will never be shared with non secure nodes. Third parties will only be allowed to host such secure servers if strict security can be proven and guaranteed.
For the most part, no records in the DB will ever be modified. They will all instead have chronological copies showing a history of the values. When a new modification is made, a new version of the record, with the current time, will be submitted. When browsing, the most recent record will be used, unless an "as_of" time is selected during browsing for historical purposes. We want to be able to look at the state of the Canonizer's data at any time in the Canonizer's history.
Each Canonizer node will have two sources of data. First, from a user submitting a change or new record. The node will query a master control node (perhaps done previously as a set, and cached) to get the unique identifier for the new record. This new record with its unique identifier will then be stored in the node's DB. Once this change is committed locally, this node will have a small number of "peers" in the network.
This replication process will be the second source of data for each canonizer node. Such replication would be initiated by a very efficient query to see of the peer already has the data. If not, the data will be replicated to the node that does not yet have it, and the process will repeat from this peer, to all of it's peers as fast as possible keeping that data in all nodes as updated as possible.
Non secure canonizer nodes, will not take data from users, but will only receive non secure replicating data from the network.

Edit summary : First Version
Submitted on :
Submitter Nick Name : Brent_Allsop
Go live Time :