Request for ideas: New developer FAQ

New developers need quite a time to familiarize themselves with the rules and conventions in PEAR. With the new role of mentors in PEAR2, they will have a contact person they can ask in that cases.
But in many cases the same questions will get asked which will get boring for the mentoring developer, so we need a Mini-FAQ with a list of things the newbie should know.

Which information should go onto that list in your eyes? Comments appreciated!

– cweiske

This entry was posted in Group Blog. Bookmark the permalink.

4 Responses to Request for ideas: New developer FAQ

  1. General FAQ:

    Q: How do I get a username ?

    Q: How do I send in a new package ?

    Q: How can I contact the developers of a package ?

    Q: Where do I send my patches to ?

    Q: How do I report a bug ?

    Developers FAQ:

    Q: How do I get access to commit ? (Karma)

    Q: Is there a way to generate a package2.xml ?

    Q: How do I start the documentation for my packages?

    Q: Where can I discuss about this and that topic ?

    Q: What is allfiles.php and why do we have that ?

    Q: Do I really need to prefix classes of a package with PEAR2_ ?? Why ?

    I believe those will be some questions we might see.

  2. Stuff I notice alot of with the current system:

    Q: What happens during a PEPR proprosal?
    A: You have an idea for a package, and some code already. You write up a bit of documentation, and show your idea off to the world. It goes through a number of stages, from draft to proposed to voting. Usually, you’ll be grilled by existing developers.

    Q: Why are all of these people picking on my PEPR proprosal, and why do they sound nasty?
    A: They aren’t actually trying to be nasty, they are trying to be helpful – they just come across a little cantankerous. Many of these people would like to see your proposal in PEAR, provided it solves a problem. Many of these people are just trying to maintain consistency within PEAR itself…

    Q: What maximizes my chances of getting a proposal through?
    Make sure it’s a relevant proposal, make sure it’s well documented, provide .phps so that other developers can view your coding style, provide Really Simple API examples. The better your level of documentation, examples and availability of code, the better your chances are.
    Additionally, it never hurts to ask on the developer mailing lists for feedback.

    Q: How do I name a package correctly?

    Q: Where do I put/categorize a package?

  3. Pingback:

  4. Pingback: » PEAR Blog: Request for ideas: New developer FAQ

Comments are closed.