Visit the forum instructions to learn how to post to the forum, enable email notifications, subscribe to a category to receive emails when there are new discussions (like a mailing list), bookmark discussions and to see other tips to get the most out of our forum!
Re: Web Infrastructure Forum writeable by team members
  • Since the forum was locked in the original thread, I just had a question. What is the definition of a contributor? As an engineer I may have a technical opinion on something in a pivotal project. Posting that in the forums would count as a contribution. This might be a specific component, and may consist of as little as one post.

    I think the rationale for separating access like this is to separate the "talkers" from the "doers" so that the "doers" aren't hindered. In that case, these restricted subforums should not be related to entire projects, but to specific components of those projects, like team report-outs, action items, status updates, deliverables, etc. Things like designs, technology choices, and other high-level things should be open to everyone, because everyone is a potential contributor in that area, by the very fact of them posting.

    One could already consider everyone who is on this forum as a "Level 1 contributor" or "contributor by default". The solar fire project thread is a good example. Under a completely closed project forum system, there either couldn't be such a discussion, or it would have to be done in general discussion. So perhaps a two-tiered access system would be best?
  • 8 Comments sorted by
  • I'd hope that the form this took was more segregation than restriction.  To keep from spamming the general forum, project collaborations are of course separate.  But to enable people to learn about them, learn about details, decide if they want to become contributors, they always have full access to everything - like any open source style github project, their contributions will be gatewayed through the managers and leads on the project - but they're never stopped from doing the equivalent of downloading source code and trying it out, and making patches.

    This brings to the fore the importance of having tools to work with for collaboration that are so much a part of the process that they are ALWAYS up to date.  That only happens when they ARE the mechanism that is used actualize the activity - even if its slightly artificial.  

    A for instance would be, if you have a design change for your micro tractor, you get on the system and make the change *in the state of the collaboration system* - THEN someone (perhaps the same person) actualizes the change by USING the new state of the system - instead of doing the more historically typical pattern of making the change physically, THEN if you get around to it, changing media to the computer, where you modify the design and upload it to the system if you have time/inclination.  It is important to pay the overhead of running the design in all its iterations through the information tools up front so it gets done - fundamental auditability with collaboration allows us to learn the best.  This way, the state of the design is always SHARED, which is absolutely critical to collaboration.

  • @jason

    > What is the definition of a contributor?

    OSE defines it as someone who completes a task associated with an OSE project as documented on the Pivotal project tracking application.  Since you have to be invited to participate in a Pivotal project, there is an initial period of negotiation between you and the project leader.  While this does create a barrier to entry in an OSE project, it's necessary, to some degree.  Speaking as one of OSE's few project managers, I want people on my team who will make a serious contribution.  I don't want someone who will constantly complain about poor decisions, etc.  Instead, I want someone who will intelligently discuss project plans and make positive suggestions for how we might improve things and then help me make it happen.

    It has been decided that the OSE project forums will be tools dedicated to the projects themselves.  As such, they will be restricted to Contributors.  Others will still be able to view the conversation.  If they truly have something to say or contribute, they have two options open to them:  make a post in the General Discussion forum, or send email to the project manager.  Using either approach, HOW you make the suggestion will be as important as WHAT you suggest.


    >  the importance of having tools to work with for collaboration that are
    so much a part of the process that they are ALWAYS up to date.

    That's the goal, though it is a work in progress, naturally.  Yes, the project forums are more segregated than exclusive.  Hopefully, this will increase the signal to noise ratio in the project forums, which will in turn encourage those who should use it.  If you (or anyone else) truly wants to participate in an OSE project forum, then become a contributor.  OSE is a meritocracy - which means that people are given abilities according to their merits - largely measured by what they contribute.  Complaining, whining, and personal attacks are a negative contribution that we really don't want or need (not that I'm saying that you do this).

    For more information, have a look at Forum Policy (Link updated - Elifarley).  It was substantially updated this morning.

  • Hello mjn,

    I have some doubts about the OSE definition of contributor, as you stated in your last post: 
    How to contribute to the design of a tool that don't have  a project leader yet?
    How to contribute to  something that is outside the top 50 GVCS tools?
    How to contribute to change one of the 50 GVCS tools?
    Is a contributor someone tha is contributing with content to the wiki?
    Is a contributor someone that is working to translate the wiki pages to other languages?

    OBS: There is currently no text in the forum policy page.
  • Thanks for the explanation mjn, as well as the update to the wiki. It is good to point out similarities with other successful open source project structures, for those of us who aren't familiar with the process. As long as we are following a standardized process, I'm much more comfortable with it.

    I would like to challenge the team, however, as we move forward, to consider what differences there might be between an open source software project and an open source hardware project. Some obvious differences would be that anyone can download code and compile it, relatively easily. However, to get a piece of hardware built and running is a completely different matter. Also, the "interfaces" between hardware can be almost trivial - the interface to a renewable power source might be the ability to charge 12 volt batteries, for example.

    My main point is that, I agree with you, the project forums should be tightly controlled to create a structured and dynamic team. However, grouping the specific project implementation and the technology being implemented in the same forum could be a bad thing. For example, lets say the tool needed is a windmill. There may be a dozen different viable options for a windmill, that have different pros and cons. If one team "has the windmill" and exclusive access to its associated technology forums, it is difficult to have on-going discussions about different windmill technologies, open sourcing someone else's windmill designs, or a guy making his own version and updating it. In the software world, you generally don't have this problem - you've got a tightly managed piece of code that is THE code. Everyone downloads it, everyone uses it, its not perfect but it is continually being "maintained". You aren't constantly thinking about better ways to architect it because that would take man months or years. With hardware, every time you built one you are literally building it with your own hands. Its not problematic to have a different version - all it has to do is charge the batteries.

    My solution would be that perhaps the function should be separated from the implementation. The implementation is the tightly managed project you talk about, the larger technology/function discussion should be an open, ongoing discussion, in a separate subforum. Perhaps the team will come up with a different solution for the differences described above; I just want these things to be brought to everyone's attention.

    Perhaps I'm saying the same things as Fabio but in a much less concise way.
  • @Fabiofranca

    > How to contribute to the design of a tool that don't have  a project leader yet?

    Fill out the Team Culturing Survey, which should give you access to the wiki.  Then add stuff to the wiki in appropriate places.  If your contributions advance the development of a particular GVCS tool (etc) to the point where the project will be started, you are likely to be invited to participate, having made a substantial contribution.  In general, the role of Contibutor applies to OSE forums at this time - later is might have more meaning.  Early on, only the active GVCS projects will have technical forums.  Others will be added as they come up to speed.

    I should note that the information I'm giving you is my current understanding.  It is not my intention to represent the OSE leadership team as a whole or to create OSE policy.
  • A link worth reading, though will work better, the period threw it off.
  • LOL.  Done in by punctuation!  That's what I get for trying to combine web culture and good sentence structure.

  • Instead of using the "General Discussions" category for IT issues and web infrastructure issues, we could use a more specific category like this newly created one:

    Discussions started there can be moved to the core IT category if necessary (and the person who started the discussion can also be invited to the core IT team so that he/she can make further posts).

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Login with Facebook Sign In with Google Sign In with OpenID Sign In with Twitter

In this Discussion