Organizational Suggestions
Robert Hafner
1. Separate "Standards" (PSR's) from "Bylaws"
Right now there is a lot of discussion regarding the functioning of this group. Things like membership levels and rights, voting procedure, member responsibilities, and even simpler stuff like the actual format of the PSR's are all things that should be discussed, decided on and then published so that way people actually know them.
This group already has a basic process for making standards- someone forks the repository, draws their plans up, and then issues a pull request. From there discussion continues on Github through the use of issues and code annotation, and overall meta conversations occur on the list. Once something reaches a point where people are happy the changes get merged. It seems to me like the bylaw process should be similar.
What I'm proposing is a new place for storing bylaws- either a folder in the existing repository, or a whole new repository under the same organization. They should also be given a nice title (PSB- PHP Standards Bylaws or something) and numbering scheme, like the standards themselves. Unlike the code standards they'll need to be more dynamic- while the standards are meant for interoperability, these are meant for human organization and should evolve as time goes on. Github is perfect for this as those changes can be made in the form of PRs that are then discussed and voted on.
The benefits here are huge. For one thing, a public list of rules will stop the "how do we do this" questions that come up all the time. It also makes these discussions about policy a lot easier to follow, as the individual components will be in their own issues or pull requests.
2. New Repository for Standard Code
There are a number of new proposals which include code, such as interfaces, which will be needed by implementing libraries. As some point some of these proposals will actually get accepted, at which point the interfaces are going to need to be distributed to the projects that use them.
I think the best way to handle this is to split this code out into it's own repository. This will let projects work with just the code, rather than pulling down all of the standards (and maybe even bylaws) just to access thing. Composer support can be added to make things even easier.
3. New Repository For Official Examples
Finally, a lot of proposals end up with people asking for example implementations to get an idea for how things should work. There are example Autoloaders for PSR-0, and people have asked about ones for the caching proposal. These shouldn't be mixed in with code required for implementing the standards, but it might be useful to have them in one place.
Beau Simensen
Handrus Nogueira
I like the direction of these ideas. It would make things a lot easier if we can point to something that has been written that describes the bylaws type stuff rather than rehashing it in several emails based on various people's memories. It would also be nice to have a separation between the code (final interfaces, etc.) and the standard definition.
To view this discussion on the web visit https://groups.google.com/d/msg/php-standards/-/U6hnDVrFsGgJ.--
You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.
To post to this group, send email to php-st...@googlegroups.com.
To unsubscribe from this group, send email to php-standard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/php-standards?hl=en.
Handrus Stephan Nogueira