Brainstorming an idea

[NodeWest-Dan]

Although we'd want to keep it in the VPSboard family, why not put it under its own name/domain to keep everything straight?  

 

[NodeBytes]

It would be.

 

[BuyCPanel-Kevin]

Doesn't sound like a bad idea, who would decide the rankings/jobs though? You have any projects already in mind?

 

[NodeBytes]

That would be the harder part.

I personally think rank should be decided by a combination of dedication and skill. It would make sense to choose who is in charge by how much work/time they put in and how able they are to get work done.

 

[telephone]

While I like the idea of a large project/team, it has a high probability of stalling or failing. Unless you have lead developers with a lot of interest and a set amount of spare time, you'll eventually run into issues.

In saying that, I think having mini-projects (small teams) where interested parties volunteer, would work well. This is how I picture the setup:

------------------------------------------------------------------

Stage #1:

- Have a recruitment system (vpsBoard sub-section). Users will post their ideas with requirements (language, number of developers, timeline)

- These "ideas" will then be up for discussion. Interested parties can talk logistics and gauge interest

- The top X (two or three at a time) will be given the green light

    - These projects receive full hosting/support by the sponsoring entity

Stage #2:

- Interested parties will sign-up to be on the developing team for said project (list # of hours available per week)

- A lead developer (or two) will be assigned

- Developer team will be selected

    - Include 1-2 novice developers to mentor (depending on team size)

** Majority of projects would only require 2-3 developers **

Stage #3:

- Collaboration software and Git repo will be setup for team members

- If requested, a continuous integration server OR a VPS with an isolated environment will be assigned for the project

Stage #4:

- Lead developer/s will be in charge of initial planning, including:

    - Framework (by majority vote)

    - Code assignment -> Split the project into X sections

    - Coding standards

    - Directory structure

    - Database structure

    - Class structure -> Interfaces/Abstracts

- Once initial planning/setup is complete, team members will be assigned (or choose) their section of code. E.g. Front-end UI, database interaction/management, API development, etc...

    - Novice developers will be teamed up with another member, where they can interact/learn

Stage #5:

- Public Git repo

- Interested parties can keep up to date with development, and interact with developers/submit pull requests

Stage #6:

- Committed code will be peer reviewed (lead developer/s should do this anyway)

- UNIT TESTS!!!

Stage #7:

- Release compiled/packaged code once completed

- Maybe vpsBoard, or fellow low end companies would sponsor the project (once complete)

------------------------------------------------------------------

With the above system, a wider array of projects will be released, and you're more likely to push code/have less stalled projects (as only interested parties would sign-up).

The other point to consider is the number of willing (and knowledgeable) developers. If there are only a handful of intermediate/senior developers willing to help, fewer projects will be undertaken.

 

[wlanboy]

 

Some notes to your well written post.

Stage #1:

- Have a recruitment system (vpsBoard sub-section). Users will post their ideas with requirements (timeline)

It will be hard to figure out at that stage that you need 40 mandays to develop somethings.

Or that 4 developers for 10 weeks doing 8 hours a week to build a tool.

I like the idea of a a recruitment center where stakeholders can find product owners.

The product owner (lead developer) is offering an architecture and a rough plan how things should be done.

You might even call that the product owner is offering a solution.

- These "ideas" will then be up for discussion. Interested parties can talk logistics and gauge interest

- The top X (two or three at a time) will be given the green light

    - These projects receive full hosting/support by the sponsoring entity

The "top x" will be "voted" by the people joining the product owner.

The only limit is the number of developers.

One developer is only allowed to join one project at a time.

And the developers are offering services (unit: 1 manday (MD) per month).

The product owner then has to decide if he takes the offers or decline them.

Stage #2:

- Interested parties will sign-up to be on the developing team for said project (list # of hours available per week)

Yup at that time the "services" will sum up and this will be the base for the project plan (timeline).

- A lead developer (or two) will be assigned

That will be the product owner which offered a solution.

- Developer team will be selected

    - Include 1-2 novice developers to mentor (depending on team size)

** Majority of projects would only require 2-3 developers **

That limit would destory the idea of pair programming - double that amount.

Stage #3:

- Collaboration software and Git repo will be setup for team members

- If requested, a continuous integration server OR a VPS with an isolated environment will be assigned for the project

And the tests are setup -> test driven development.

If we want that open approach to develop things the first line of codes should always be tests.

Stage #4:

- Lead developer/s will be in charge of initial planning, including:

    - Framework (by majority vote)

Allready done. The developers offered "services" like 5 MD per month for JS development".

    - Code assignment -> Split the project into X sections

Allready done by the architecture.

    - Coding standards

    - Directory structure

    - Database structure

    - Class structure -> Interfaces/Abstracts

Yup that has to be done by the team,

- Once initial planning/setup is complete, team members will be assigned (or choose) their section of code. E.g. Front-end UI, database interaction/management, API development, etc...

    - Novice developers will be teamed up with another member, where they can interact/learn

The team is defining a story board (list of things to do).


Each story is about one aspect (use case) of the system.

Then one developer takes the resposiblity for this story and is developing it.


Your right one story will have a defined place like API, UI, etc.


But if a developer wants to do more he can define a story that is including UI and API

Stage #5:

- Public Git repo

This is a public repro by design - right at the beginning.

If I am doing something wrong I want to have feedback as soon as possible.

Hey let everyone - who might be interested! - my code is boring review it right from the beginning.

- Interested parties can keep up to date with development, and interact with developers/submit pull requests

Second that!

Submit what you want - hey you would do my work!

Stage #6:

- Committed code will be peer reviewed (lead developer/s should do this anyway)

- UNIT TESTS!!!

Sorry but this is my first nope.


Don't ever do tests when everything is done.

Noone will create all tests needed (hey it is running!) and noone will check if the tests are testing all requirements.

Stage #7:

- Release compiled/packaged code once completed

- Maybe vpsBoard, or fellow low end companies would sponsor the project (once complete)

It's git so the team will tag releases but hopefully that project will never end.

But your're right if all tests are green the project is finished and the developers can join other teams.

 

[NodeBytes]

Also... there are multiple ways to do the same thing in many languages, but not all are compatible with the desired overall design of the app/script that is being built. Just worth mentioning for further discussion.

I would recommend as a requirement for working on these projects that strong documentation of how each part of the code functions and what part it plays in the overall function be in place.

 

[telephone]

Some notes to your well written post.

Thanks for your comments wlanboy, I agree with most of your points, but wanted to criticize a few  .

Stage #1:


- Have a recruitment system (vpsBoard sub-section). Users will post their ideas with requirements (timeline)

It will be hard to figure out at that stage that you need 40 mandays to develop somethings.

Or that 4 developers for 10 weeks doing 8 hours a week to build a tool.

I like the idea of a a recruitment center where stakeholders can find product owners.

The product owner (lead developer) is offering an architecture and a rough plan how things should be done.

You might even call that the product owner is offering a solution.

1) Yes, during the initial stage it will just be a rough outline, but I expect those who pitch ideas to have taken their due diligence and researched their idea... I at least expect the components involved and/or bullet points of their findings.

    - E.g.  "... script" already does "...", so I think it would be beneficial to use that as the base, and simply interact with the response

    - E.g. "I think PHP would be the ideal language as ..."

2) Those who pitch, are not always going to lead the development. Just because they've come up with the idea doesn't mean they have the spare time, or the experience to lead a small dev team.

To expand, those who pitch the idea could be junior developers with limited experience. (E.g. Maybe they only code procedurally). Personally, I'm not going to work under that person. No offence meant to them, but they should be a team member and not the lead.

This is only if there is no initial code base.

3) The owner of the pitch should state their intentions in the initial outline.


    - Their position: Lead developer, team member, bystander (just proposing idea)


    - What license are you proposing to release under: MIT, BSD, GPL (v2/v3), etc..


    - How will you document the team members contributions


    - Etc...

4) If the owner of the pitch isn't the lead developer and the project is started from nil (no initial code base), I feel the product owner should be ALL the team members with one or two selected as product maintainers.

5) This would be uncommon, but what happens if no developers come forward for the proposed architecture, but X developers state their interest if another architecture is used.


    - Proposed language is Node.js, but X developers announce their interest if it was developed in Ruby

    - Proposed framework is CodeIgniter, but X developers prefer Laravel

 I feel a team vote would be a better solution (unless there's an initial code base, or only the lead is an intermediate/senior developer).

Stage #4:


- Once initial planning/setup is complete, team members will be assigned (or choose) their section of code. E.g. Front-end UI, database interaction/management, API development, etc...


    - Novice developers will be teamed up with another member, where they can interact/learn

The team is defining a story board (list of things to do).


Each story is about one aspect (use case) of the system.

Then one developer takes the resposiblity for this story and is developing it.


Your right one story will have a defined place like API, UI, etc.


But if a developer wants to do more he can define a story that is including UI and API

1) I agree. That was just to stand as an example. Developers won't be limited to their one section, but that "section" will be theirs (they're in-charge and expected to produce).

Exception would be if the lead developer runs a tyrannical dictatorship 

Stage #6:


- Committed code will be peer reviewed (lead developer/s should do this anyway)

- UNIT TESTS!!!

Sorry but this is my first nope.


Don't ever do tests when everything is done.

Noone will create all tests needed (hey it is running!) and noone will check if the tests are testing all requirements.

1) My fault for not going more in-depth. I meant developers should be coding to unit tests, and continually creating new tests for added features.

 

[BlueVM]

I would potentially be interested...

 

[blergh]

Sounds like a cool idea, and not to shit on your parade but i think it will slowly die out & go stale.

 

[NodeBytes]

@BlueVM - Awesome.

@blergh - Not to be negative, and not that I disagree, but it's worth a lot to some people to have a group like this. I would be encouraged to write more code if I had projects and a team to work with on some of the bigger projects. The team of devs I am working with now keeps everything in private repos because it's all proprietary stuff for the client we are working with. I would like to work on some fun projects that aren't necessarily proprietary nor do we have to keep private.

 

[WebSearchingPro]

This sounds like a very interesting idea, It would be a great learning opportunity for many members in the community. 

 

[wlanboy]

So let's start.

• fisle: a Email panel
• bpsRobert: a new WHMCS
• bpsRobert: a new SolusVM
• peterw: a DNS panel

Any other items on the wishlist?

So from my point of view fisle and peterw should talk to each other. Maybe they can combine their requirements?

A panel framework where we can plugin things like email or dns support. Would be nice because everyone does have other favors for servers and so everyone can add support for an additional server.

 

[NodeBytes]

I'd like a good Nginx control panel.

I'll sponsor the first project. 

 

[HalfEatenPie]

Honestly I'd be willing to help out sponsoring this or part of it personally (out of my own funds) under the vpsBoard brand  

I love how this is organized right now and would love to help out! 

 

[peterw]

I have been dreaming of creating good, simple to use email panel.

I'd like a good Nginx control panel.

So from my point of view fisle and peterw should talk to each other. Maybe they can combine their requirements?

A panel framework where we can plugin things like email or dns support.

I like the idea to have a panel with plugins for servers!

Fisle, NodeBytes can we agree on the plattform? Phyton with bottle? Because I want to learn Phyton.

I dont want install mysql, apache, php to run a dns server. So no database needed for the panel? Or only a small one like sqlite, memcached or redis?

First goal to support one dns (bind?) one mail server (postfix?) and one webserver (ngix?). Everyone ok?

 

[fisle]

I like the idea to have a panel with plugins for servers!

Fisle, NodeBytes can we agree on the plattform? Phyton with bottle? Because I want to learn Phyton.

I dont want install mysql, apache, php to run a dns server. So no database needed for the panel? Or only a small one like sqlite, memcached or redis?

First goal to support one dns (bind?) one mail server (postfix?) and one webserver (ngix?). Everyone ok?

Modular approach indeed sounds good.

Python indeed sounds good. I would suggest Flask instead of Bottle though, not really much reasoning behind this except I've already done few small private projects in it.

For start sqlite would be good IMO.

I am fine with the goals.

 

[Novacha]

Modular approach indeed sounds good.

Python indeed sounds good. I would suggest Flask instead of Bottle though, not really much reasoning behind this except I've already done few small private projects in it.

For start sqlite would be good IMO.

I am fine with the goals.

Would I be able to suggest Django?

It is very app-oriented, and would be perfect to slot plugins into (so each app controls it's own urls, views and raw templates [but extend a base template]). Django is also a feature-full framework and is easier to lift a project off the ground, which is an important thing for open source software.

Testing in Django is well done, thanks to a custom TestCase class that Django provides to make writing unit tests for views and methods easier (it creates and destroys the database on start and finish, rolls back all changes after every test, and creates a test client to send requests to views). Since a panel would also use a datastore, Django's built in ORM (with multi-database support, such as SQLite, MySQL, Postgres etc.) would come in handy. Background tasks such as running system commands would be able to use the optimised Django Celery package.

In the end, the framework used is not hugely important, as long as quality of code is maintained, though it can be a big help.

 

[peterw]

Modular approach indeed sounds good.

Python indeed sounds good. I would suggest Flask instead of Bottle though, not really much reasoning behind this except I've already done few small private projects in it.

For start sqlite would be good IMO.

I am fine with the goals.

I like the one-file idea of Bottle but Flask is supporting GET and POST in routes and does have better plugin support. After reading about Flask I think Bottle is too small for a panel project.

Do we use Phyton 2 or Phyton 3?

How should requirements look?


Flask
Jinja2
Flask-Login
Flask-Mail
WTForms
Flask-WTF
Babel
Flask-Babel
pysqlite
SQLAlchemy
Flask-SQLAlchemy
tornado
gunicorn

Do we want to use SQLAlchemy?

Do we want to use tornado or gunicorn?

 

[5n1p]

I like the one-file idea of Bottle but Flask is supporting GET and POST in routes and does have better plugin support. After reading about 

You can use GET and POST in Bottle too, but Flask is better.