Thread: [myhdl-list] MEP guidelines
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Günter D. <dan...@we...> - 2011-05-06 15:03:49
|
Hi, I would like to suggest, adding some guidelines about the MEP process. Seeing that the text of an already implemented MEP got changed, I think it would be helpfull to have some guidelines how the MEP process is intended. I think, that especially an already implemented MEP should be kept for reference as is and not changed later in time. There is the chance, that the original notion of the implementation gets altered by editing the MEP it originated from. My suggestion is to add the text to the MEP introduction page: http://myhdl.org/doku.php/meps:intro The text could be based on the Python Enhancement Proposal, found here: http://www.python.org/dev/peps/pep-0001/ Here is a first draft for a text. The first paragraphs are a copy of the PEP text, changed according to MyHDL: --------- MEP stands for MyHDL Enhancement Proposal. A MEP is a design document providing information to the MyHDL community, or describing a new feature for MyHDL. The MEP should provide a concise technical specification of the feature and a rationale for the feature. We intend MEPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into MyHDL. The MEP author is responsible for building consensus within the community and documenting dissenting opinions. MEPs are maintained on the MyHDL wiki page. The page history resembles the development history of the document. Main responsibility of a MEP lies with its author. Before opening a new MEP, its idea should be discussed on the MyHDL mailing list. In the development phase the MEP gets the status "Draft" assigned. Fully developed and provided with a functional implementation, the MEP can get the status "Final", documenting that the content of the MEP is ready to be implemented into MyHDL. Once the MEP has the status "Final" and its content got added to the source code, the MyHDL version will be added to the MEP document. From this time, the text of the document will be frozen. ------------ Cheers, Guenter |
|
From: Christopher F. <chr...@gm...> - 2011-05-06 21:08:30
|
Sounds good. But what is the process for ammending a MEP? In the example you provided, how would the MEP documentation be kept upto date with the implementation? Assuming the implementation diversion had reasons to change the MEP. Would a new MEP be created for the changes? There should be a method to add this information and the process should be added to the text. Regards, Chris On 5/6/11 10:03 AM, Günter Dannoritzer wrote: > Hi, > > I would like to suggest, adding some guidelines about the MEP process. > Seeing that the text of an already implemented MEP got changed, I think > it would be helpfull to have some guidelines how the MEP process is > intended. > > I think, that especially an already implemented MEP should be kept for > reference as is and not changed later in time. There is the chance, that > the original notion of the implementation gets altered by editing the > MEP it originated from. > > My suggestion is to add the text to the MEP introduction page: > > http://myhdl.org/doku.php/meps:intro > > The text could be based on the Python Enhancement Proposal, found here: > > http://www.python.org/dev/peps/pep-0001/ > > Here is a first draft for a text. The first paragraphs are a copy of the > PEP text, changed according to MyHDL: > > --------- > > > MEP stands for MyHDL Enhancement Proposal. A MEP is a design document > providing information to the MyHDL community, or describing a new > feature for MyHDL. The MEP should provide a concise technical > specification of the feature and a rationale for the feature. > > We intend MEPs to be the primary mechanisms for proposing new features, > for collecting community input on an issue, and for documenting the > design decisions that have gone into MyHDL. The MEP author is > responsible for building consensus within the community and documenting > dissenting opinions. > > MEPs are maintained on the MyHDL wiki page. The page history resembles > the development history of the document. > > Main responsibility of a MEP lies with its author. Before opening a new > MEP, its idea should be discussed on the MyHDL mailing list. > > In the development phase the MEP gets the status "Draft" assigned. Fully > developed and provided with a functional implementation, the MEP can get > the status "Final", documenting that the content of the MEP is ready to > be implemented into MyHDL. > > Once the MEP has the status "Final" and its content got added to the > source code, the MyHDL version will be added to the MEP document. From > this time, the text of the document will be frozen. > > ------------ > > > Cheers, Guenter > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd |
|
From: Günter D. <dan...@we...> - 2011-05-07 08:24:04
|
On 06.05.2011 23:07, Christopher Felton wrote: > Sounds good. But what is the process for ammending a MEP? In the > example you provided, how would the MEP documentation be kept upto date > with the implementation? Assuming the implementation diversion had > reasons to change the MEP. > > Would a new MEP be created for the changes? Looking at the PEP flow again, that is what they do. They create a new PEP, that runs through the stages 'Draft' and 'Final', with the remark that it is created to replace another PEP. If the PEP achieves the 'Final' state, the originating PEP will get its status changed from 'Final' to 'Replaced' In think this process could be used for the MEPs as well. Then adding a cross reference. So the old MEP gets the MEP number added by which it got replaced and the new MEP gets the number added which it replaces. That way the history of MyHDL implementation is documented by the MEP documents that achieved the status 'Final' or in the process got 'Replaced'. Where as the wiki-history of the individual document shows the development process of the MEPs. Cheers, Guenter |
|
From: Jan D. <ja...@ja...> - 2011-05-10 07:54:52
|
On 05/06/2011 11:07 PM, Christopher Felton wrote: > Sounds good. But what is the process for ammending a MEP? In the > example you provided, how would the MEP documentation be kept upto date > with the implementation? Assuming the implementation diversion had > reasons to change the MEP. I have not stated it explicitly, but, as Guenter inferred, the idea of MEPs was indeed to be for MyHDL what PEPs are for Python, and to reuse the PEP methodology. The PEP infrastructure has all we will ever need, and much more probably. Given our resources, it is too heavy to just copy it as is, but we can use the bits that we need and let it grow as our needs evolve. Case in point: A 'Final' MEP should not be changed (except typo's and language corrections from a neutral proofreader). It is intended to document the language history for experts. The lanugage documentation is in the manuals. > Would a new MEP be created for the changes? New MEP's can be created and existing ones superseded. > There should be a method to add this information and the process should > be added to the text. > > Regards, > Chris > > On 5/6/11 10:03 AM, Günter Dannoritzer wrote: >> Hi, >> >> I would like to suggest, adding some guidelines about the MEP process. >> Seeing that the text of an already implemented MEP got changed, I think >> it would be helpfull to have some guidelines how the MEP process is >> intended. >> >> I think, that especially an already implemented MEP should be kept for >> reference as is and not changed later in time. There is the chance, that >> the original notion of the implementation gets altered by editing the >> MEP it originated from. >> >> My suggestion is to add the text to the MEP introduction page: >> >> http://myhdl.org/doku.php/meps:intro >> >> The text could be based on the Python Enhancement Proposal, found here: >> >> http://www.python.org/dev/peps/pep-0001/ >> >> Here is a first draft for a text. The first paragraphs are a copy of the >> PEP text, changed according to MyHDL: >> >> --------- >> >> >> MEP stands for MyHDL Enhancement Proposal. A MEP is a design document >> providing information to the MyHDL community, or describing a new >> feature for MyHDL. The MEP should provide a concise technical >> specification of the feature and a rationale for the feature. >> >> We intend MEPs to be the primary mechanisms for proposing new features, >> for collecting community input on an issue, and for documenting the >> design decisions that have gone into MyHDL. The MEP author is >> responsible for building consensus within the community and documenting >> dissenting opinions. >> >> MEPs are maintained on the MyHDL wiki page. The page history resembles >> the development history of the document. >> >> Main responsibility of a MEP lies with its author. Before opening a new >> MEP, its idea should be discussed on the MyHDL mailing list. >> >> In the development phase the MEP gets the status "Draft" assigned. Fully >> developed and provided with a functional implementation, the MEP can get >> the status "Final", documenting that the content of the MEP is ready to >> be implemented into MyHDL. >> >> Once the MEP has the status "Final" and its content got added to the >> source code, the MyHDL version will be added to the MEP document. From >> this time, the text of the document will be frozen. >> >> ------------ >> >> >> Cheers, Guenter >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Jan D. <ja...@ja...> - 2011-05-10 08:00:03
|
On 05/06/2011 05:03 PM, Günter Dannoritzer wrote: > Hi, > > I would like to suggest, adding some guidelines about the MEP process. > Seeing that the text of an already implemented MEP got changed, I think > it would be helpfull to have some guidelines how the MEP process is > intended. Good idea. Looking at your draft however: without BDFL powers (for me) it's a no-go as for as I'm concerned, and also unworkable in practice I believe. > I think, that especially an already implemented MEP should be kept for > reference as is and not changed later in time. There is the chance, that > the original notion of the implementation gets altered by editing the > MEP it originated from. That is indeed the idea. > My suggestion is to add the text to the MEP introduction page: > > http://myhdl.org/doku.php/meps:intro > > The text could be based on the Python Enhancement Proposal, found here: > > http://www.python.org/dev/peps/pep-0001/ > > Here is a first draft for a text. The first paragraphs are a copy of the > PEP text, changed according to MyHDL: > > --------- > > > MEP stands for MyHDL Enhancement Proposal. A MEP is a design document > providing information to the MyHDL community, or describing a new > feature for MyHDL. The MEP should provide a concise technical > specification of the feature and a rationale for the feature. > > We intend MEPs to be the primary mechanisms for proposing new features, > for collecting community input on an issue, and for documenting the > design decisions that have gone into MyHDL. The MEP author is > responsible for building consensus within the community and documenting > dissenting opinions. > > MEPs are maintained on the MyHDL wiki page. The page history resembles > the development history of the document. > > Main responsibility of a MEP lies with its author. Before opening a new > MEP, its idea should be discussed on the MyHDL mailing list. > > In the development phase the MEP gets the status "Draft" assigned. Fully > developed and provided with a functional implementation, the MEP can get > the status "Final", documenting that the content of the MEP is ready to > be implemented into MyHDL. > > Once the MEP has the status "Final" and its content got added to the > source code, the MyHDL version will be added to the MEP document. From > this time, the text of the document will be frozen. > > ------------ > > > Cheers, Guenter > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Günter D. <dan...@we...> - 2011-05-10 14:46:56
|
On 10.05.2011 09:59, Jan Decaluwe wrote: > On 05/06/2011 05:03 PM, Günter Dannoritzer wrote: >> Hi, >> >> I would like to suggest, adding some guidelines about the MEP process. >> Seeing that the text of an already implemented MEP got changed, I think >> it would be helpfull to have some guidelines how the MEP process is >> intended. > > Good idea. Looking at your draft however: without BDFL powers (for me) > it's a no-go as for as I'm concerned, and also unworkable in practice > I believe. Yes, I have been thinking about that. Referring to your other post, I also agree, not to make this process too complicated. My suggestion would be, that a MEP can only achieve the final state by approval of you. That keeps the process simple and not add additional states like 'Rejected'. I updated the draft and added your case in point to it. So the updated version of the guidelines would be like this: --------- MEP stands for MyHDL Enhancement Proposal. A MEP is a design document providing information to the MyHDL community, or describing a new feature for MyHDL. The MEP should provide a concise technical specification of the feature and a rationale for the feature. We intend MEPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into MyHDL. The MEP author is responsible for building consensus within the community and documenting dissenting opinions. MEPs are maintained on the MyHDL wiki page. The page history resembles the development history of the document. Main responsibility of a MEP lies with its author. Before opening a new MEP, its idea should be discussed on the MyHDL mailing list. In the development phase, the MEP gets the status "Draft" assigned. Fully developed and provided with a functional implementation, the MEP can get the status "Final", documenting that the content of the MEP is ready to be implemented into MyHDL. The right to change the status of a MEP from "Draft" to "Final" belongs exclusively to Jan Decaluwe. Once the MEP has the status "Final" and its content got added to the source code, the MyHDL version will be added to the MEP document. From this time on, the text of the document will be frozen. A "Final" MEP should not be changed, except for spelling mistakes or language corrections from a neutral proofreader. It is intended to document the MyHDL development history for experts. The MyHDL language documentation for users is in the manuals. In case the functionality described in a MEP needs to be altered or extended, a new MEP shall be created, describing the new desired implementation. The new MEP will live through the same steps as the MEP process describes. The new MEP should cross reference the MEP its implementation is based on. In case the new MEP will replace an implementation of an existing MEP, the old MEP will achieve the status "Deprecated" as soon as the new MEP achieves the status "Final". Both MEPs should cross reference each other. ------------ Hope this did not become too complicated :) If there are no objections to these guidelines, I will put them on the wiki page. Cheers, Guenter |
|
From: Jan D. <ja...@ja...> - 2011-05-18 16:14:49
|
Guenter: I notice no objections, and for me this is fine also. I propose to add this info, so that the rules are explicitly clear, and because some MEPs need maintenance. Jan On 05/10/2011 04:46 PM, Günter Dannoritzer wrote: > On 10.05.2011 09:59, Jan Decaluwe wrote: >> On 05/06/2011 05:03 PM, Günter Dannoritzer wrote: >>> Hi, >>> >>> I would like to suggest, adding some guidelines about the MEP process. >>> Seeing that the text of an already implemented MEP got changed, I think >>> it would be helpfull to have some guidelines how the MEP process is >>> intended. >> >> Good idea. Looking at your draft however: without BDFL powers (for me) >> it's a no-go as for as I'm concerned, and also unworkable in practice >> I believe. > > Yes, I have been thinking about that. Referring to your other post, I > also agree, not to make this process too complicated. > > My suggestion would be, that a MEP can only achieve the final state by > approval of you. That keeps the process simple and not add additional > states like 'Rejected'. > > I updated the draft and added your case in point to it. So the updated > version of the guidelines would be like this: > > --------- > MEP stands for MyHDL Enhancement Proposal. A MEP is a design document > providing information to the MyHDL community, or describing a new > feature for MyHDL. The MEP should provide a concise technical > specification of the feature and a rationale for the feature. > > We intend MEPs to be the primary mechanisms for proposing new features, > for collecting community input on an issue, and for documenting the > design decisions that have gone into MyHDL. The MEP author is > responsible for building consensus within the community and documenting > dissenting opinions. > > MEPs are maintained on the MyHDL wiki page. The page history resembles > the development history of the document. > > Main responsibility of a MEP lies with its author. Before opening a new > MEP, its idea should be discussed on the MyHDL mailing list. > > In the development phase, the MEP gets the status "Draft" assigned. > Fully developed and provided with a functional implementation, the MEP > can get the status "Final", documenting that the content of the MEP is > ready to be implemented into MyHDL. > > The right to change the status of a MEP from "Draft" to "Final" belongs > exclusively to Jan Decaluwe. > > Once the MEP has the status "Final" and its content got added to the > source code, the MyHDL version will be added to the MEP document. From > this time on, the text of the document will be frozen. A "Final" MEP > should not be changed, except for spelling mistakes or language > corrections from a neutral proofreader. It is intended to document the > MyHDL development history for experts. The MyHDL language documentation > for users is in the manuals. > > In case the functionality described in a MEP needs to be altered or > extended, a new MEP shall be created, describing the new desired > implementation. The new MEP will live through the same steps as the MEP > process describes. The new MEP should cross reference the MEP its > implementation is based on. > > In case the new MEP will replace an implementation of an existing MEP, > the old MEP will achieve the status "Deprecated" as soon as the new MEP > achieves the status "Final". Both MEPs should cross reference each other. > > ------------ > > Hope this did not become too complicated :) > > If there are no objections to these guidelines, I will put them on the > wiki page. > > Cheers, Guenter > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Jan D. <ja...@ja...> - 2011-05-18 18:58:57
|
On 05/06/2011 05:03 PM, Günter Dannoritzer wrote: > Hi, > > I would like to suggest, adding some guidelines about the MEP process. > Seeing that the text of an already implemented MEP got changed, I think > it would be helpfull to have some guidelines how the MEP process is > intended. > > I think, that especially an already implemented MEP should be kept for > reference as is and not changed later in time. There is the chance, that > the original notion of the implementation gets altered by editing the > MEP it originated from. Now that we have the guidelines, let me comment on that particular edit itself, which I found very problematic. First, the document in question was clearly marked as "Final". I think that makes it obvious that one should be very careful when editing, regardless of any guidelines. Second, the edit was about an issue that the editor was clearly struggling with. He had received several references, as well as repeated advice to study an introductory text to HDL-based design. Still, he felt confident enough to make a drastic edit. Most importantly, the edit content was completely wrong, both in the details and in the concepts. My conclusion: wiki's don't work, at least not the "democratic" access rights part of them. As a result, I'm changing the policy to grant edit access to myhdl.org. Instead of a simple request, I will require a demonstrated level of experience with MyHDL. I have already implemented this by restoring content as appropriate, updating the page about access request, and updating the existing access rights. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Günter D. <dan...@we...> - 2011-05-18 19:54:01
|
On 18.05.2011 20:58, Jan Decaluwe wrote: ... > > My conclusion: wiki's don't work, at least not the "democratic" > access rights part of them. I believe it is a combination of things, namely: - the amount of content in the wiki - the size of the community that takes part in editing it - the ratio of advanced to beginner level - the sensibility vs boldness of beginner level to know when to edit or when not to edit content I believe, with the amount of content in the MyHDL wiki and the size of the community taking part in editing it, it is wise to restrict access. As a single bold beginner can have a big impact and the social aspect of a big community does not work here. Fortunately, dokuwiki has a good way to do restriction with access rights. > > As a result, I'm changing the policy to grant edit access to > myhdl.org. Instead of a simple request, I will require a > demonstrated level of experience with MyHDL. I have already > implemented this by restoring content as appropriate, updating > the page about access request, and updating the existing > access rights. I think a good idea would be, to grant new users a user space where they are allowed to edit. There they could demonstrate the level of experience, without changing other content of the page. Here is an idea to extend this thought. At the moment there is in the top side bar an entry for "Users & Projects". Following that link will lead to the "intro" page in the projects namespace, with entries of users of MyHDL. Looking at the links there, I see some people have just edited their content in the 'projects' namespace - like myself. Others have done a mix. Some content is in the 'projects' namespace. Other is in the 'users' namespace. Here is an idea for beginners. If someone get's a new account to the wiki, that user will get an entry in the projects:intro page - edited by the admin. That entry is a link to 'users:<login name>'. The new user can only edit content under the namespace 'users:<login name>'. That way it is possible to contribute to the page, but restrict editing access to users namespace. Cheers, Guenter |
|
From: Christopher F. <chr...@gm...> - 2011-05-18 20:58:16
|
<snip> > > Here is an idea for beginners. > > If someone get's a new account to the wiki, that user will get an entry > in the projects:intro page - edited by the admin. That entry is a link > to 'users:<login name>'. The new user can only edit content under the > namespace 'users:<login name>'. That way it is possible to contribute to > the page, but restrict editing access to users namespace. > > Cheers, > > Guenter > I like that idea. One it helps the mechanics, I am one of those mixed contributors :) Users can create projects, content, proposed, MEPs, etc in the user-space. As an example, proposed MEPs can be started in the user-space and at some point they can be moved to the official area. This assumes all official content supersedes user content. This adds more work to the maintainer but will give users the freedom to add content. And it clear what content is user additions vs. myhdl content. Chris |
|
From: Günter D. <dan...@we...> - 2011-05-18 21:11:30
|
On 18.05.2011 22:57, Christopher Felton wrote: ... > > I like that idea. One it helps the mechanics, I am one of those mixed > contributors :) ... just to make sure, I might have worded that bad. I did not mean that mixing the namespaces for content is something bad. I was not even aware that there is a users namespace until later I stumbled upon a link. That is the only reason why I have my content all under the projects namespace. ;) Guenter |
|
From: Jan D. <ja...@ja...> - 2011-05-19 10:08:26
|
On 05/18/2011 11:11 PM, Günter Dannoritzer wrote: > On 18.05.2011 22:57, Christopher Felton wrote: > ... >> >> I like that idea. One it helps the mechanics, I am one of those mixed >> contributors :) > > ... just to make sure, I might have worded that bad. I did not mean that > mixing the namespaces for content is something bad. I was not even aware > that there is a users namespace until later I stumbled upon a link. That > is the only reason why I have my content all under the projects > namespace. ;) No worries - the reason for the two namespaces is simply that originally some people started adding content under "users", other under "projects". But it's really the same type of info, so what I did is join it and link the "users" sidebar to the "projects" sidebar to make things transparent. Slightly confusing when you look at the namespace details, I agree. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Jan D. <ja...@ja...> - 2011-05-19 10:15:19
|
On 05/18/2011 09:53 PM, Günter Dannoritzer wrote: > On 18.05.2011 20:58, Jan Decaluwe wrote: > ... >> >> My conclusion: wiki's don't work, at least not the "democratic" >> access rights part of them. > > I believe it is a combination of things, namely: > > - the amount of content in the wiki > - the size of the community that takes part in editing it > - the ratio of advanced to beginner level > - the sensibility vs boldness of beginner level to know when to edit or > when not to edit content > > I believe, with the amount of content in the MyHDL wiki and the size of > the community taking part in editing it, it is wise to restrict access. > As a single bold beginner can have a big impact and the social aspect of > a big community does not work here. Fortunately, dokuwiki has a good way > to do restriction with access rights. > >> >> As a result, I'm changing the policy to grant edit access to >> myhdl.org. Instead of a simple request, I will require a >> demonstrated level of experience with MyHDL. I have already >> implemented this by restoring content as appropriate, updating >> the page about access request, and updating the existing >> access rights. > > I think a good idea would be, to grant new users a user space where they > are allowed to edit. There they could demonstrate the level of > experience, without changing other content of the page. > > Here is an idea to extend this thought. > > At the moment there is in the top side bar an entry for "Users& > Projects". Following that link will lead to the "intro" page in the > projects namespace, with entries of users of MyHDL. Looking at the links > there, I see some people have just edited their content in the > 'projects' namespace - like myself. Others have done a mix. Some content > is in the 'projects' namespace. Other is in the 'users' namespace. > > Here is an idea for beginners. > > If someone get's a new account to the wiki, that user will get an entry > in the projects:intro page - edited by the admin. That entry is a link > to 'users:<login name>'. The new user can only edit content under the > namespace 'users:<login name>'. That way it is possible to contribute to > the page, but restrict editing access to users namespace. All possible and meaningful, but even then, it's reasonable to assume that one has to complete a significant MyHDL project before being able to contribute meaningful content. I think I'll still ask for that first. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Christopher F. <chr...@gm...> - 2011-05-19 11:11:03
|
On 5/19/2011 5:12 AM, Jan Decaluwe wrote: > On 05/18/2011 09:53 PM, Günter Dannoritzer wrote: >> On 18.05.2011 20:58, Jan Decaluwe wrote: >> ... >>> >>> My conclusion: wiki's don't work, at least not the "democratic" >>> access rights part of them. >> >> I believe it is a combination of things, namely: >> >> - the amount of content in the wiki >> - the size of the community that takes part in editing it >> - the ratio of advanced to beginner level >> - the sensibility vs boldness of beginner level to know when to edit or >> when not to edit content >> >> I believe, with the amount of content in the MyHDL wiki and the size of >> the community taking part in editing it, it is wise to restrict access. >> As a single bold beginner can have a big impact and the social aspect of >> a big community does not work here. Fortunately, dokuwiki has a good way >> to do restriction with access rights. >> >>> >>> As a result, I'm changing the policy to grant edit access to >>> myhdl.org. Instead of a simple request, I will require a >>> demonstrated level of experience with MyHDL. I have already >>> implemented this by restoring content as appropriate, updating >>> the page about access request, and updating the existing >>> access rights. >> >> I think a good idea would be, to grant new users a user space where they >> are allowed to edit. There they could demonstrate the level of >> experience, without changing other content of the page. >> >> Here is an idea to extend this thought. >> >> At the moment there is in the top side bar an entry for "Users& >> Projects". Following that link will lead to the "intro" page in the >> projects namespace, with entries of users of MyHDL. Looking at the links >> there, I see some people have just edited their content in the >> 'projects' namespace - like myself. Others have done a mix. Some content >> is in the 'projects' namespace. Other is in the 'users' namespace. >> >> Here is an idea for beginners. >> >> If someone get's a new account to the wiki, that user will get an entry >> in the projects:intro page - edited by the admin. That entry is a link >> to 'users:<login name>'. The new user can only edit content under the >> namespace 'users:<login name>'. That way it is possible to contribute to >> the page, but restrict editing access to users namespace. > > All possible and meaningful, but even then, it's reasonable to > assume that one has to complete a significant MyHDL project before > being able to contribute meaningful content. I think I'll still > ask for that first. > > Sounds perfectly reasonable to me. Chris |
|
From: Jan C. <jan...@mu...> - 2011-05-19 12:15:41
|
On 19/05/11 11:12, Jan Decaluwe wrote: > . . . >> >> If someone get's a new account to the wiki, that user will get an entry >> in the projects:intro page - edited by the admin. That entry is a link >> to 'users:<login name>'. The new user can only edit content under the >> namespace 'users:<login name>'. That way it is possible to contribute to >> the page, but restrict editing access to users namespace. > > All possible and meaningful, but even then, it's reasonable to > assume that one has to complete a significant MyHDL project before > being able to contribute meaningful content. I think I'll still > ask for that first. I'll volunteer to try to become a well-mannered contributor:) At some point I'd like to post details of the j1 SOC project. I would only post working code, and host development elsewhere. The expected source code size for working demo is: Software: cross compiler & support tools 25kB Hardware: source & test - MyHDL 25kB Details of original Verilog based project are here: http://www.excamera.com/sphinx/fpga-j1.html Jan Coombs -- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X