Talk:Project policy

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)

Developers makes it fairly clear that anyone can contribute. The login page has a link for creating an account. I think it fairly likely that anyone who will successfully manage to contribute to the project will be able to figure that out. I think this wiki is intended to be fairly public. I'm reasonably sure this discussion belongs somewhere else--perhaps K5wiki:Positioning the wiki or some such. --SamHartman 17:04, 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)

I think it is fine for people to include less than is required for approval in a project proposal. However without a design I don't think the project should be approved; I think a "sounds like a good start; finish this off" response is fine. I think we may be agreening with each other. The question may be what changes do we need to make to the policy to make this more clear. --SamHartman 17:00, 10 April 2008 (EDT)

I think we agree. However the wording of this section needs work. It's not clear to me from the doc what the point of the early stage is. If this is for the initial discussion of whether a project has a chance of approval then this should be fleshed out more.

The wording of the project proposal section should make it clear as what sections are absolutely needed for the early stage and what sections are optional at the early stage.

--Will Fiveash 16:19, 10 April 2008 (CDT)

I think the answer should be that nothing is required at the early stage. I think nothing should be required to take a project to review, except a belief on the project proponents' part that they will get useful review feedback. Perhaps we should have two review templates--one for an optional review stage trying to determine if there is sufficient interest and one for review targeted at approval. Keep in mind that it's sort of tricky what's a requirement here. Ultimately if the world's broken and we need to act quickly, things are going to happen fast process requirements or no process requirements; you can always ask for forgiveness either. I'm not sure there should be any hard requirements, but I think there are some things we cannot imagine approving a project without and I think that corresponds fairly closely to the list in the current policy. I do think making it clear that you don't need all of those sections before initially discussing a project would be good.

--SamHartman 18:18, 10 April 2008 (EDT):::--SamHartman 18:18, 10 April 2008 (EDT)