K5Wiki - User contributions [en]

Talk:Developer resources

2008-04-24T01:32:47Z

Estone:

no place for info about compatibility issues between implementations -- should it go here?
--[[User:Estone|Estone]] 21:27, 23 April 2008 (EDT)

Also, mailing lists are listed on the Kerberos web site -- should be synced here. Or pick one location and link to it.

Information that is in 2 different places and is written up differently is confusing.

--[[User:Estone|Estone]] 21:32, 23 April 2008 (EDT)

Talk:Developer resources

2008-04-24T01:27:14Z

Estone: New page: no place for info about compatibility issues between implementations -- should it go here? --~~~~

no place for info about compatibility issues between implementations -- should it go here?
--[[User:Estone|Estone]] 21:27, 23 April 2008 (EDT)

Documentation

2008-04-22T20:46:09Z

Estone:

Placeholder for pointers to:

* current versions of documentation

* list of documents under revision

* links

--[[User:Estone|Estone]] 16:46, 22 April 2008 (EDT)

Talk:Documentation

2008-04-22T20:45:29Z

Estone:

Why is this page appropriate for k5wiki? Note that the point of the wiki is to be a resource for those developing MIT Kerberos. IT seems that most of our docs are for those using MIT Kerberos either as developers, administrators or end-users. There is a significant difference between developers using MIT Kerberos and developers developing MIT Kerberos.
--[[User:SamHartman|SamHartman]] 10:08, 25 March 2008 (EDT)

Good point. Should it exist at all? I was thinking of it being a documentation status page: what's in progress, what's next in the queue. Since it's not really participatory, does it belong on the internal web site? It might be nice to keep krbmit apprised.

:You said this in person. That addresses my concerns. --[[User:SamHartman|SamHartman]] 04:22, 11 April 2008 (EDT)

Should we solicit input from developers on docs? Specific bugs go into the bug database, but do we want to know if they think we're missing a manual that should exist?

:No. We should solicit sponsors for information on what docs we should write. Steve has basically done that.
:--[[User:SamHartman|SamHartman]] 04:22, 11 April 2008 (EDT)

Perhaps a documentation section on the public web page, with links to latest-n-greatest versions of docs?

--[[User:Estone|Estone]] 21:57, 10 April 2008 (EDT)

clarified purpose and status of this page.

--[[User:Estone|Estone]] 16:45, 22 April 2008 (EDT)

Talk:Documentation

2008-04-22T20:44:22Z

Estone:

Documentation

2008-04-22T20:42:52Z

Estone:

Placeholder for pointers to:

* current versions of documentation

* list of documents under revision

* links

----

Talk:Documentation

2008-04-11T01:57:55Z

Estone:

Why is this page appropriate for k5wiki? Note that the point of the wiki is to be a resource for those developing MIT Kerberos. IT seems that most of our docs are for those using MIT Kerberos either as developers, administrators or end-users. There is a significant difference between developers using MIT Kerberos and developers developing MIT Kerberos.
--[[User:SamHartman|SamHartman]] 10:08, 25 March 2008 (EDT)

Good point. Should it exist at all? I was thinking of it being a documentation status page: what's in progress, what's next in the queue. Since it's not really participatory, does it belong on the internal web site? It might be nice to keep krbmit apprised.

Should we solicit input from developers on docs? Specific bugs go into the bug database, but do we want to know if they think we're missing a manual that should exist?

Perhaps a documentation section on the public web page, with links to latest-n-greatest versions of docs?

--[[User:Estone|Estone]] 21:57, 10 April 2008 (EDT)

K5Wiki talk:Positioning the wiki

2008-04-11T01:44:32Z

Estone: New section: prequel

Per Sam's comment on the [[http://k5wiki.kerberos.org/wiki/Talk:Project_policy Project Policy talk page]], this is a how-we-present ourselves page. What information is exposed where, and what information should be very easy to find will help consortium members feel that the wiki (and the web site) are easy to use. If it's easy to use, it will get used.

My mileage varies -- I'm not a seasoned developer in the opensource community, and I might suggest too much detail. On the other hand, I've had a hard time figuring out how to use and contribute to this wiki. Will Kerberos newbies (or opensource newbies) have the same problem?

Right now, there isn't a cohesive outline or site-wide Table of Contents. For example, I bookmarked the site to open up to AllPages because I can't get there from anywhere else.

--[[User:Estone|Estone]] 21:04, 10 April 2008 (EDT)

== prequel ==

''I'll add the links back in later...''

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.

LaTex offers 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.

Talk:Project policy

2008-04-11T01:36:35Z

Estone: /* re: Sam's comment about adding another page */

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. --[[User:SamHartman|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:
<pre>
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:
</pre>

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. --[[User:SamHartman|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.
:: --[[User:Wfiveash|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. --[[User:SamHartman|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 [http://web.mit.edu/kerberos/ 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 [http://www.eclipse.org/projects/dev_process/development_process.php 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 [http://www.latex-project.org/code.html Development Code] page. I know we have links to our various mailing lists on the [http://web.mit.edu/kerberos/ 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 [http://www.latex-project.org 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 [http://dev.mysql.com 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 [http://forums.mysql.com forum page].

There's also [http://opensourcehowto.org 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.

--[[User:Estone|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. --[[User:SamHartman|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.

--[[User:Wfiveash|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. --[[User:SamHartman|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.

::--[[User:Wfiveash|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.
:::--[[User:SamHartman|SamHartman]] 18:18, 10 April 2008 (EDT):::--[[User:SamHartman|SamHartman]] 18:18, 10 April 2008 (EDT)

re: Sam's comment about adding another page

[http://k5wiki.kerberos.org/wiki/K5Wiki:Positioning_the_wiki Done.]

I've copied my comments over to the new [http://k5wiki.kerberos.org/wiki/K5Wiki:Talk:Positioning_the_wiki talk page ].
--[[User:Estone|Estone]] 21:34, 10 April 2008 (EDT)

Talk:Project policy

2008-04-11T01:34:13Z

Estone: New section: re: Sam's comment about adding another page

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. --[[User:SamHartman|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:
<pre>
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:
</pre>

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. --[[User:SamHartman|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.
:: --[[User:Wfiveash|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. --[[User:SamHartman|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 [http://web.mit.edu/kerberos/ 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 [http://www.eclipse.org/projects/dev_process/development_process.php 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 [http://www.latex-project.org/code.html Development Code] page. I know we have links to our various mailing lists on the [http://web.mit.edu/kerberos/ 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 [http://www.latex-project.org 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 [http://dev.mysql.com 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 [http://forums.mysql.com forum page].

There's also [http://opensourcehowto.org 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.

--[[User:Estone|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. --[[User:SamHartman|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.

--[[User:Wfiveash|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. --[[User:SamHartman|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.

::--[[User:Wfiveash|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.
:::--[[User:SamHartman|SamHartman]] 18:18, 10 April 2008 (EDT):::--[[User:SamHartman|SamHartman]] 18:18, 10 April 2008 (EDT)

== re: Sam's comment about adding another page ==

[http://k5wiki.kerberos.org/wiki/K5Wiki:Positioning_the_wiki Done.]

I've copied my comments over to the new [http://k5wiki.kerberos.org/wiki/K5Wiki:Talk:Positioning_the_wiki talk page ].
--[[User:Estone|Estone]] 21:34, 10 April 2008 (EDT)

K5Wiki:Positioning the wiki

2008-04-11T01:27:06Z

Estone:

== Planning the Wiki Evolution ==

This page is about avoiding a "how this wiki works, and where the heck is it" page. Right now, the wiki looks a bit like an untamed garden. It's worth looking at other opensource web sites and seeing how they use their wikis. Ease-of-use has a lot to do with "getting what you expect."

Format and content guidelines belong elsewhere.

Potential topics:

* What information is available in the wiki, and have we noted places where contributions would be welcome? Is any one person(?) responsible for keeping an eye on it?

* How is it organized -- is it easy to see the relationships between topics (which "child" page belongs to which "parent"? This should take the roadmap into account -- I don't think we've planned page stubs for contributors, and that could make wiki evolution more coherent.

* What level of information is available to who -- and when should we provide pointers to more specialized information? What, if anything, is confidential? How can an unprivileged person ask about that info?

* How do you find your way around? This is more of a design issue -- it probably belongs to the wiki-owners, not in the wiki itself.

This also relates to the re-design of the Kerberos Consortium web site, w/r/t ease of navigation and access to levels of information. It might be a good idea to link the wiki with the site page.

--[[User:Estone|Estone]] 21:27, 10 April 2008 (EDT)

K5Wiki talk:Positioning the wiki

2008-04-11T01:04:48Z

Estone: New page: Per Sam's comment on the http://k5wiki.kerberos.org/wiki/Talk:Project_policy Project Policy talk page, this is a how-we-present ourselves page. What information is exposed where, and w...

K5Wiki:Positioning the wiki

2008-04-11T00:50:30Z

Estone:

== Planning the Wiki Evolution ==

This page is about avoiding a "how this wiki works" page. Right now, the wiki looks a bit like an untamed garden. It is to our advantage to present users, contributors, and founders with a clear and consistent structure. We can define the purpose and scope of the wiki so that contributors have a better chance at contributing in the right places.

Formatting and content guidelines belong elsewhere.

Potential topics:

* How information can be organized (categories, groups, etc.) to keep it as unambiguous as possible. That is, making it easy to decide which "child" page belongs to which "parent." This should take the roadmap into account -- I don't think we've planned page stubs for contributors so that they don't have to invent their own.

* Who has should have access to different levels of information.

* How to improve the navigatability of the wiki. Right now, there is no site-wide Table of Contents, and there aren't a lot of hyperlinks between pages.

This also relates to the re-design of the Kerberos Consortium web site, w/r/t ease of navigation and access to levels of information.
--[[User:Estone|Estone]] 20:50, 10 April 2008 (EDT)

K5Wiki:Positioning the wiki

2008-04-11T00:23:57Z

Estone: New page: == Planning the Wiki Evolution == This page will describe the structure and organization of this wiki. It will be easier to use and contribute to it if the structure/outline and TOCs are...

== Planning the Wiki Evolution ==

This page will describe the structure and organization of this wiki. It will be easier to use and contribute to it if the structure/outline and TOCs are as clear as possible. It would be nice to avoid explanatory text ("how this wiki is organized") if possible. Right now, there is no site-wide Table of Contents, and "stub" pages are pretty randomly put together.

This also relates to the re-design of the Kerberos Consortium web site, w/r/t ease of navigation and access to levels of information.

--[[User:Estone|Estone]] 20:23, 10 April 2008 (EDT)

K5Wiki:Todo

2008-04-10T18:34:38Z

Estone:

* Add articles describing roles: [[Developers]], [[Committers]], [[Krbcore]] and [[Release Engineers]]
* Write text on [[How to contribute]]
* Take a stab at a [[Release planning|release planning policy]]
* Include information on the 1.7 release
* Fill in the release target templates and set up release project categories
* Move coding style into the wiki and expand it a lot.
* Describe API and ABI issues

And of course much more

* Add page for Documentation work
* Either add content to Community Portal page, or hide it from outsiders altogether.

Talk:Coding style/C

2008-04-10T18:30:02Z

Estone: New page: We appear to have 2 ''Coding Style'' pages, and an hook for a link on the ''How to contribute page''. How about one article/page on Coding Style, and fix the link accordingly? --~~~~

We appear to have 2 ''Coding Style'' pages, and an hook for a link on the ''How to contribute page''. How about one article/page on Coding Style, and fix the link accordingly?

--[[User:Estone|Estone]] 14:30, 10 April 2008 (EDT)

Talk:How to contribute

2008-04-10T18:18:49Z

Estone: New section: how the others do it...

ers:

Began page with links to relevant wikimedia information. Is this too redundant (you can find this info via Help) or is it useful to give a task-oriented pointer?

: I think a task-oriented pointer is useful. I have added some stuff explicitly referring to the Wikipedia Manual of Style. A few other things are useful to have direct pointers to. The Wikipedia and MediaWiki references may be too voluminous for basic tasks.--[[User:TomYu|TomYu]] 00:23, 3 April 2008 (EDT)

: I think the current level of detail is fine for now, although things may need to get broken out as more content develops. --[[User:SamHartman|SamHartman]] 11:28, 3 April 2008 (EDT)

== how the others do it... ==

I noticed that ''How to contribute'' pages on other opensource sites refer to contributing to ''development'', not contributing to the wiki. I think we should divide this into 2 pages, explicitly titled ''How to contribute to Kerberos'' and ''How to contribute to this wiki''.

--[[User:Estone|Estone]] 14:18, 10 April 2008 (EDT)

Talk:Project policy

2008-04-10T18:12:03Z

Estone: New section: let no one else's work evade your eyes...

Talk:Project policy

2008-04-10T16:14:31Z

Estone: Undo revision 308 by Estone (Talk)

Talk:Project policy

2008-04-10T16:09:36Z

Estone: /* Submitting a project for review needs work */

Talk:How to contribute

2008-04-03T00:30:08Z

Estone: New page: ers: Began page with links to relevant wikimedia information. Is this too redundant (you can find this info via Help) or is it useful to give a task-oriented pointer?

ers:

Began page with links to relevant wikimedia information. Is this too redundant (you can find this info via Help) or is it useful to give a task-oriented pointer?

How to contribute

2008-04-03T00:27:48Z

Estone:

/*Follow the style guidlines as given in Wikimedia */

[http://meta.wikimedia.org/wiki/Help:Contents#For_editors General Information About Editing Wiki Pages]

[http://meta.wikimedia.org/wiki/Help:Wikitext Wikimedia Text Mark-Up]

[http://meta.wikimedia.org/wiki/Help:MediaWiki_help_policy#Templates_2 Templates]

[http://meta.wikimedia.org/wiki/Wikimedia_content Content Guidelines]

How to contribute

2008-04-03T00:22:44Z

Estone:

How to contribute

2008-04-03T00:20:59Z

Estone:

How to contribute

2008-04-03T00:13:24Z

Estone:

/*Follow the style guidlines as given in Wikipedia */

== Contribution guidelines ==

[http://en.wikipedia.org/wiki/Wikipedia:List_of_guidelines Wikipedia's Contribution Guidelines]

==
Wikipedia Formatting Styles ==

[http://en.wikipedia.org/wiki/Wikipedia:Cheatsheet Wikipedia Cheatsheet]

How to contribute

2008-04-03T00:07:45Z

Estone:

==
Wikipedia Formatting Styles ==

[http://en.wikipedia.org/wiki/Wikipedia:Cheatsheet Wikipedia Cheatsheet]

How to contribute

2008-04-02T23:54:12Z

Estone:

==
Wikipedia Styles ==

[//http://en.wikipedia.org/w/index.php?title=Wikipedia:Cheatsheet&oldid=197426360]

Documentation

2008-03-25T16:37:12Z

Estone:

Document
Legacy (date, location)
Plans for revision
Release target for document

Tools

Resources

--[[User:Estone|Estone]] 12:36, 25 March 2008 (EDT)

Documentation

2008-03-25T16:36:48Z

Estone:

== Kerberos Documentation ==

Document
Legacy (date, location)
Plans for revision
Release target for document

Tools

Resources

--[[User:Estone|Estone]] 12:36, 25 March 2008 (EDT)

Documentation

2008-03-24T20:26:30Z

Estone: This page lists the documents for Kerberos and their respective statuses.

Kerberos Documentation

Document
Legacy (date, location)
Plans for revision
Release target for document

Tools

Resources

Main Page

2008-03-11T20:01:53Z

Estone:

'''K5Wiki''' is a wiki for the development of [[MIT Kerberos]], a reference implementation of [[wp:Kerberos (protocol)|the Kerberos network authentication protocol]]. MIT Kerberos is a project of the [http://www.kerberos.org/ MIT Kerberos Consortium].

Here are some starting points:
* [[How to contribute]]
* [[:Category:Policies|Policies for development]]
* [[:Category:projects|Ongoing projects ]]
* [[K5Wiki:Todo|A todo list for work needing doing on this wiki]]

We look forward to your contributions to K5Wiki and MIT Kerberos.

K5Wiki:Todo

2008-03-10T17:40:56Z

Estone:

* Add articles describing roles: [[Developers]], [[Committers]], [[Krbcore]] and [[Release Engineers]]
* Write text on [[How to contribute]]
* Take a stab at a [[Release planning|release planning policy]]
* Include information on the 1.7 release
* Fill in the release target templates and set up release project categories
* Move coding style into the wiki and expand it a lot.
* Describe API and ABI issues

And of course much more

* Add page for Documentation work
* Refine U R Here, linking to sections on same page or child articles

Main Page

2008-03-10T17:38:07Z

Estone:

Main Page

2008-03-10T17:37:32Z

Estone:

Main Page

2008-03-10T17:30:54Z

Estone:

How to contribute

2008-03-10T17:14:59Z

Estone: /* U R Here: Getting Started with the Kerberos Consortium */

How to contribute

2008-03-08T04:21:01Z

Estone: /* U R Here: Getting Started with the Kerberos Consortium */

== U R Here: Getting Started with the Kerberos Consortium ==

[rough outline, pick on it at will. I'll move it to a more sensible area of the wiki on Monday]

accounts , permissions, certificates
where to find source code, this wiki, etc.
pointers to IS&T pages
setting up email
MIT calendar
email address book
set up jabber

----

meetings:
Monday 3:30
Tuesday, 11:00 (group work session)

----

Who knows what?
Internal Resources

Kerberos folk -- area of expertise and assorted info (i.e., windows help, etc.)
Bryan
Leo

ers

How to contribute

2008-03-08T04:20:13Z

Estone: /* U R Here: Getting Started with the Kerberos Consortium */

== U R Here: Getting Started with the Kerberos Consortium ==

[rough outline, pick on it at will]

accounts , permissions, certificates
where to find source code, this wiki, etc.
pointers to IS&T pages
setting up email
MIT calendar
email address book
set up jabber

----

meetings:
Monday 3:30
Tuesday, 11:00 (group work session)

----

Who knows what?
Internal Resources

Kerberos folk -- area of expertise and assorted info (i.e., windows help, etc.)
Bryan
Leo

How to contribute

2008-03-08T04:19:13Z

Estone: New page: == U R Here: Getting Started with the Kerberos Consortium == [rough outline, pick on it at will] accounts , permissions, certificates where to find source code, this wiki, etc. pointers...