Difference between revisions of "Talk:Project policy"

Revision as of 14:38, 10 April 2008

I don't see a link from the project policy on the k5wiki to code change/integration policy. So I do not know if a code review is necessary and what sort of testing is expected.

There is not a formalized code review policy. Certainly requesting specific code review as part of the community review of a project would be fine. --SamHartman 12:08, 4 April 2008 (EDT)

Submitting a project for review needs work

The "Submitting a project for review" section indicates the submitter should:

To start the review period :

   1. Replace {{project-early}} with {{project-review|end_of_review_date}}
   2. Add {{subst:project-vote}} at the bottom of the project page.
   3. Send mail to krbdev@mit.edu including:

But after saving the project page after following steps 1 & 2, this text appears on the project page:

   An announcement has been sent to krbdev@mit.edu starting a review of
   this project. That review will conclude on 2008-04-18.

This is confusing as it sounds like step 3 was done automatically by the wiki. If the wiki is sending out notification automatically (and I think it should) then step 3 should be removed.

The Wiki cannot send out mail. The procedure is correct, but the text on the project page assumes that you actually follow the directions and send the mail. --SamHartman 12:08, 4 April 2008 (EDT)

I think the wording of the project-review template needs to be changed to avoid the ambiguity. Something like:

   The project owner should have sent an announcement to krbdev@mit.edu starting a review of
   this project. That review will conclude on 2008-04-18.

--Will Fiveash 12:42, 4 April 2008 (CDT)

I think updating the policy to make it clear that you need to send the mail but that the page will say that mail is sent would be good. I think that updating the template will be more confusing than desirable. I'll also update the template docs. --SamHartman 13:51, 4 April 2008 (EDT)

let no one else's work evade your eyes...

This is mostly about meta-issues, like how to find project policies for other opensource projects (with links to same) than it is about the content of the policies themselves(project as in opensource entity, like MySQL, not as in a development project for said entity. This is what you get when you hire a tech writer.)

How we make this information available implies how easy it is to contribute to an existing project vs. how easy it is to propose a project (and affect the general road map). Some opensource projects hide this information from the general public, restricting it to members.

Come to that, I don't see any obvious information about how to become a "member" on our wiki-- i.e.,set up an account with wiki-editing privileges for the Kerberos wiki. I think all you get is an error message that you have to log in to edit a page (is it the same for talk?). There's nothing at all on the public web site about membership/contribution, nor is there any mention or link to the public wiki. Do we want to control access to information about this level of development? I think this is inherently part of the policy -- who can even find this information? (I think this topic should be considered w/r/t the new website design.)

Eclipse presents this information on the Development Process page. It's pretty structured -- do we want to be this formal? Requests and complaints about policy are entered into the bug log. There's also a link to the version-in-progress, and a link to the diffs between it and the current version.

The Wiki cannot send out mail. The procedure is correct, but the text on the project page assumes that you actually follow the directions and send the mail. --SamHartman 12:08, 4 April 2008 (EDT)

LaTex gets around this by offering mailing lists to which anyone can subscribe on their Development Code page. I know we have links to our various mailing lists on the public web site but nothing explicit about a mechanism for using a list to send mail for this purpose Maybe it should be part of the policy page in the wiki? Is that an appropriate use for a mailing list? I hesitate to recommend a separate mailing list for such things (we already have so many!).

BTW, LaTex names their website LaTex Project, which implies that it's not so much a product as an ongoing development process. What we call things affects others' perceptions.

MySQL has a very slick site with a tab for Developer Zone. FWIW, I don't like the site itself because it looks too corporate, not like a friendly opensource home page. I didn't delve into it, but it looks like their policy requires potential developers to pass a certification test. They also have a very nice forum page.

There's also OpenSource HowTo, but it's intended for novices. BTW, I searched on "kerberos" and it only appeared buried in articles about other opensource programs.

Obviously, I could cite examples forever -- so I'll stop now.

--Estone 14:12, 10 April 2008 (EDT)

Proposing a project Issue

In the Proposing a project section there is this list of elements a project proposal should have:

• A description of the desired change in functionality
• Any functional requirements that must be met for the project to be successful
• A design for how the desired functionality will be implemented
• A breakdown of tasks or milestones to judge progress of the project
• Screenshots or other proposed user interface descriptions
• Documentation and sample code for any APIs that are proposed
• Dependencies on other projects
• Information on desired integration and release goals
• Testing plan

My issue with the above is that having to include a design, documentation and test plan in the initial project proposal is too burdensome. I think the initial proposal must include:

• A description of the desired change in functionality
• Any functional requirements that must be met for the project to be successful
• A breakdown of tasks or milestones to judge progress of the project
• Screenshots or other proposed user interface descriptions
• Dependencies on other projects
• Information on desired integration and release goals

and the following would be optional in the initial proposal but would have to be submitted for further review if the initial proposal was accepted:

• A design for how the desired functionality will be implemented
• Documentation and sample code for any APIs that are proposed
• Testing plan

So the idea would be that someone could submit a light weight project proposal and if that is approved they would follow up with more detail which would then be reviewed.

--Will Fiveash 14:35, 10 April 2008 (CDT)