I'd like to put a basic guidelines for commit messages up for a vote.

The basic rules should read:

The intent of this guide is to reduce friction when working with code written by different authors. It does so by enumerating a shared set of rules and expectations about how to write good commit messages to enhance the ability to understand what, how and why people did something.

The guidelines rules herein are derived from many other guidelines for commit messages. When various authors collaborate across multiple projects, it helps to have one set of guidelines to be used among all those projects. Thus, the benefit of this guide is not in the rules themselves, but in the sharing of those rules.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

1. The seven rules of a great Git commit message (the reference is in each rule)

1. Subject MUST be separated from body with a blank line
2. Subject line MUST be limited by 50 characters
3. Subject line MUST be capitalized
4. Subject line MUST NOT end with period
5. Subject line MUST be using the english imperative mood
6. Body MUST be wrapped at 72 characters
7. Body MUST be used to explain what and why vs. how

2. Commit messages language

Commit messages MUST be in english.

Voting should be 👍, 👎 or self-declared abstentions.
Voting will close when all 7 voting members have cast their votes, or at February 9th 2017, at 12:20 BRST. If no minimum quorum (5 members) is met by then, the vote will fail and will have to be restarted.

We've approved that all components must be distributed under the MIT License.

However, the MIT License requires a copyright holder.

I think we should keep it simple and not reference the CONTRIBUTORS.md file, since contributors may change over time. IMO, it'd be better to have PHP Object Library - PHPOL as the copyright holder.

I'm putting this up for a vote. If you don't concur, please comment with an alternative suggestion.

--
Voting should be 👍, 👎 or self-declared abstentions.
Voting will close when all 8 voting members have cast their votes, or at February 10th 2017, at 13:45 BRST. If no minimum quorum (5 members) is met by then, the vote will fail and will have to be restarted.

Hi! We are currently voting on issues. But I'm not really sure of when to halt the vote. Who are the core members? Who can vote? When is the voting stopped?

My proposal: As of right now, every contributor, independent of merit, should be able to vote on issues. Issues should be held open for 2 days, then the voting is closed. If we reach a consensus before the stipulated date, the issue can be closed. However, to close prematurely, we should have a majority (50% + 1) of votes AND require a vote from every contributor.

Rules and bylaws should require a 2/3 vote, whereas technical votes should require 50% + 1 votes of contributors (not of total votes).

I'm sponsoring @marcossffilho as voting member.

Yay oy Nay (:+1:)/(:-1:)

Hi! In all the hurry to get coding, we forgot to talk about licenses.

I'd like to open a vote that requires all components to be distributed under the MIT license.

Voting should be 👍, 👎 or self-declared abstentions.
Voting will close when all 7 voting members have cast their votes, or at February 9th 2017, at 15:50 BRST. If no minimum quorum (5 members) is met by then, the vote will fail and will have to be restarted.

Suggestion for style and general coding guide:

• PSR2
• Object Calisthenics

Any other ideias?

I'd like to put a basic contribution and specs proposition up for a vote.

The basic rules should read:

The intent of this guide is to reduce friction when working with code written by different authors. It does so by enumerating a shared set of rules and expectations about how to write PHP code.

The style rules herein are derived from de facto standards adopted from the community at large, and commonalities between the voting members. When various authors collaborate across multiple projects, it helps to have one set of guidelines to be used among all those projects. Thus, the benefit of this guide is not in the rules themselves, but in the sharing of those rules.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

1. Overview

• Code MUST adhere to PSR-2.
• Autoloading and file names MUST be PSR-4 compliant.
• Code SHOULD follow Object Calisthenics rules.
• API changes MUST adhere to the Semantic Versioning schema.
• Code MUST be accompanied by its respective unit tests. Full (100%) coverage is expected.

Voting should be 👍, 👎 or self-declared abstentions.
Voting will close when all 7 voting members have cast their votes, or at February 9th 2017, at 9:02 BRST. If no minimum quorum (5 members) is met by then, the vote will fail and will have to be restarted.

I'd like to put a basic guidelines for commit messages up for a vote.

The basic rules should read:

The intent of this guide is to reduce friction when working with code written by different authors. It does so by enumerating a shared set of rules and expectations about how to write good commit messages to enhance the ability to understand what, how and why people did something.

The guidelines rules herein are derived from many other guidelines for commit messages. When various authors collaborate across multiple projects, it helps to have one set of guidelines to be used among all those projects. Thus, the benefit of this guide is not in the rules themselves, but in the sharing of those rules.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

1. The seven rules of a great Git commit message (the reference is in each rule)

1. Subject SHOULD be separated from body with a blank line
2. Subject line SHOULD be limited by 50 characters
3. Subject line SHOULD be capitalized
4. Subject line SHOULD NOT end with period
5. Subject line SHOULD be using the english imperative mood
6. Body SHOULD be wrapped at 72 characters
7. Body SHOULD be used to explain what and why vs. how

2. Commit messages language

Commit messages MUST be in english.

Voting should be 👍, 👎 or self-declared abstentions.
Voting will close when all 7 voting members have cast their votes, or at February 9th 2017, at 15:45 BRST. If no minimum quorum (5 members) is met by then, the vote will fail and will have to be restarted.

Here are my suggestion about the 3 primary components to be written.

• String
• Array
• Number

This is the first component Vote, more will follow this one and Votes should be done as per rules defines on this repository.

--

Proposal

Implement the first component as being OL\String.

String should be the component responsible for handling anything string related, there was some code samples but the general roadmap will be explained bellow:

Part 1

Implement common and most used functions, fully tested

Part 2

Implement less used functions, test for full UTF-8 support

Part 3

Map remaining String functions on PHP Core and decide on it's implementation or not.

Options:

Vote in favor of this being the first implemented component:

• 👍 (:+1: ) for voting Yes.
• 👎 (:-1: ) for voting No.

Please thumbs up/down on this very message, suggestions and discussion can be made on the comments.

I'd like to put a Numeric component up for a vote.

This component should handle the formatting and casting of the numeric types. Initially, I'm planning to implement the Integer type, and later the Float.

If this component gets approval, I'll open another thread with the specification and details about the Integer implementation.

Voting should be 👍, 👎 or self-declared abstentions.
Voting will close when all 7 voting members have cast their votes, or at February 9th 2017, at 16:03 BRST. If no minimum quorum (4 members) is met by then, the vote will fail and will have to be restarted.

Hello!

I createed a Array manipulation library inspired by this project and I want to provide my code, contributing for this library.

Link of repo

This is a reserved thread so we can discuss which namespace to use.

Hi! I'd like to propose a removal of all current repositories under the phpol namespace (except for this one, phpol/phpol, obviously), up until we define which libraries will be created, under which name. We currently have a String and Array repositories, none of which were voted, some with sample codes on master.

Hi.

I see we've created a few repositories, some with sample code. I'd like to discuss a few things, before we get hands-on.

What's the goal of the library? Is it to port the structured nature of PHP to a more OOP approach? Or are we going to take the chance to enhance it, somehow?

This is a very important discussion before the hands-on. For example, I see someone has created an Array repository. If we are to enhance the native types, should we not discuss Arrays x Collections? Collections packages, similar to System.Collections from .NET provides, could implement not only arrays (which would be a collection type), but also ordered lists, linked lists, dictionaries, and others.

Can we take a moment to talk about those issues?

I'd like to put a Collections component up for a vote. This component should be comprised of collection data types, with an initial Array implementation.

I will not specify an Array implementation just yet, because I'd like to take this chance to just reserve the phpol/collections namespace.

Futurely, I intend to add Set, Dictionary, LikedList, DoubleLinkedList and OrderedList datatypes, at least.

If this is approved, I will put Array up for a vote in a separate thread, so we can talk about its goals, syntax, and technical specifications.

Voting should be 👍, 👎 or self-declared abstentions.
Voting will close when all 7 voting members have cast their votes, or at February 9th 2017, at 9:32 BRST. If no minimum quorum (4 members) is met by then, the vote will fail and will have to be restarted.